Server device

Abstract

To minimize the possibility of a vehicle becoming inoperable even when a program update fails.SOLUTION: An in-vehicle device 6 includes a program storage unit 64 that stores a program, a startup processing unit 65 that starts the program, and an update processing unit 63 that receives a program update program 21 and a reason for update 22 and updates the program using the update program 21. If the program update fails, the startup processing unit 65 starts the program in a startup mode corresponding to the reason for update 22.SELECTED DRAWING: Figure 1

Description

[Technical Field]

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

[0002] It is known that in-vehicle devices that have installed programs, such as an ECU (Electronic Control Unit) or a gateway ECU that controls a vehicle, the programs are updated using OTA (Over The Air) or the like. In this type of in-vehicle device, if an event occurs during a program update, such as power being cut off to the in-vehicle device (hereinafter also referred to as a "power outage"), the program update may fail. In this case, the in-vehicle device generally starts the program in a degenerate mode that only performs the program update, and in the worst case, the vehicle may enter a state in which it is unable to operate normally (hereinafter also referred to as an "inoperable state"). Patent Document 1 discloses a technology that starts a simple program and performs vehicle evacuation driving even if the program update is not performed normally. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Laid-Open No. 2010-125925 Summary of the Invention [Problem to be solved by the invention]

[0004] The technology disclosed in Patent Document 1 is expected to reduce the likelihood of the vehicle becoming inoperable by activating a simple program and driving the vehicle to an evacuation site when a program update fails. However, the technology disclosed in Patent Document 1 has room for improvement, as there is a risk that the vehicle may become inoperable if the simple program has a functional defect or the like.

[0005] The present invention has been made in view of the above, and has an object to minimize the possibility of a vehicle becoming inoperable even when a program update fails. [Means for solving the problem]

[0006] In order to solve the above problem, the in-vehicle device of the present invention comprises a program memory unit that stores a program, a startup processing unit that starts the program, and an update processing unit that receives an update program and a reason for the update for the program and updates the program using the update program, and is characterized in that if the update of the program fails, the startup processing unit starts the program in a startup mode that corresponds to the reason for the update. [Effects of the Invention]

[0007] According to the present invention, it is possible to minimize the possibility of the vehicle becoming inoperable even when a program update fails. Problems, configurations, and effects other than those described above will become apparent from the following description of the embodiments. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 is a diagram showing the configuration of a program update system according to a first embodiment. [Figure 2] 2 is a diagram showing an update reason table referred to by the activation mode determination unit shown in FIG. 1; [Figure 3] FIG. 2 is a sequence diagram showing the processing of the program update system shown in FIG. [Figure 4] 4 is a flowchart of a function determination process performed in S116 shown in FIG. 3. [Figure 5] FIG. 10 is a diagram showing the configuration of a program update system according to a second embodiment. DETAILED DESCRIPTION OF THE INVENTION

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

[0010] [Embodiment 1] A program update system 1 according to the first embodiment will be described with reference to FIGS. Fig. 1 is a diagram showing the configuration of a program update system 1 of embodiment 1. Fig. 2 is a diagram showing an update reason table 8 referenced by the start-up mode determination unit 652 shown in Fig. 1.

[0011] In this embodiment, the program update system 1 determines the program startup mode in the in-vehicle device 6 using update data 20 acquired from the server device 2 when an update of a program installed in the in-vehicle device 6 fails for some reason and it becomes impossible to determine the storage surface (hereinafter also referred to as the "startup surface") of the program storage unit 64 where the program is stored and can be started. 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 some other method instead of acquiring it from the server device 2.

[0012] The program update system 1 includes a vehicle 3 equipped with an on-board 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 a "program update notification") notifying that the program stored in the program storage unit 64 will be updated with the update data 20, and transmits the update notification to the vehicle 3.

[0014] The update data 20 includes an update program 21 for updating a 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 a communication bus 31. The communication bus 31 is physically 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 standards of the communication bus 31 are, for example, CAN (registered trademark), LIN (registered trademark), FlexRay (registered trademark), 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 with the server device 2 and the gateway device 5. The communication processing unit 41 receives 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 configured with 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 having the CPU load into the RAM and execute each program that describes the OTA processing unit 51 and the communication processing unit 53 and that is stored in the ROM.

[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 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 configured with a non-volatile storage device and stores the update data 20. The communication processing unit 53 has a communication interface function with 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 a "program update request") requesting that the program stored in the program storage unit 64 be updated with the update data 20, and transmits the update data 20 to the in-vehicle device 6 with the update data 20 attached. The method of transmitting the program update request and the update data 20 to the in-vehicle device 6 is not particularly limited. The OTA processing unit 51 may transmit the received update data 20 to the in-vehicle device 6 via the communication processing unit 53 without storing the data 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 configured with a CPU, a ROM, a RAM, etc. 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 into the RAM and executing the programs that describe 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, which are stored in the ROM. The in-vehicle device 6 may be an ECU that controls the vehicle 3.

[0020] The update processing unit 63 receives the program update request sent from the gateway device 5 and the update data 20 added to the update request via the communication processing unit 61. The communication processing unit 61 has a communication interface function with 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 a 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 outage occurs before the update of the program is completed, it can determine that the update of the program has failed. Note that the update processing unit 63 may use the received update data 20 to update 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 multiple memory 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 a program (program A or program B) stored in the program storage unit 64. As a result, the startup processing unit 65 starts the in-vehicle device 6. The startup processing unit 65 includes a startup screen determination unit 651, a startup mode determination unit 652, and a startup execution unit 653.

[0024] The launch surface determination unit 651 determines whether a launch surface can be determined from among the multiple storage surfaces held by the program storage unit 64. That is, the launch surface determination unit 651 determines whether a program stored in any of the multiple storage surfaces held by the program storage unit 64 can be successfully launched. In the in-vehicle device 6, if an update of a program stored in the program storage unit 64 fails due to an event such as a battery power outage, launch surface determination information previously set in the program storage unit 64 or the launch processing unit 65 may be lost. The launch surface determination unit 651 can determine whether a launch surface can be determined by determining whether the launch surface determination information has been lost. If the launch surface determination unit 651 is able to determine a launch surface, it notifies the launch execution unit 653 of information about the determinable launch surface in order to launch the program stored on the determinable launch surface. If the launch surface determination unit 651 is unable to determine a launch surface, it can determine that the update of the program stored in the program storage unit 64 has failed. If the launch screen determination unit 651 is unable to determine the launch screen, it notifies the launch mode determination unit 652 that the launch screen cannot be determined, in order to determine the launch mode of the program.

[0025] The startup mode determination unit 652 determines the startup mode of a program stored in the program storage unit 64. The startup mode is a method for starting a program stored in the program storage unit 64. If an update of a 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, if the update of the program fails and the launch screen determination unit 651 is unable to determine the launch screen, 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 via the update processing unit 63.

[0026] The startup mode determination unit 652 refers to a predetermined update reason table 8, identifies a 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 an update reason ID 81, which is identification information for the update reason 22, with the content 82 of the update reason 22, and a startup mode 83 corresponding to the update reason 22. The startup mode 83 defines how the program is to be started, and includes the setting content of the startup mode.

[0027] The update reason table 8 can be created arbitrarily depending on the configuration of the program update system 1. The update reason table 8 may be set in advance in the in-vehicle device 6, including the startup mode determination unit 652, or may be included in the update data 20. Furthermore, if the update reason 22 is corrupted for some reason and becomes unreadable, the startup mode determination unit 652 may determine that the program stored in the program storage unit 64 should be started in degenerate mode, and notify the startup execution unit 653 of this.

[0028] Even if the update of a program stored in the program storage unit 64 fails, if the launch surface determination unit 651 is able to determine the launch surface, the launch execution unit 653 launches the program stored in the determinable launch surface. The launch mode in this case is the normal launch mode that was used when the program was successfully launched before the update. On the other hand, if the update of the program fails and the launch surface determination unit 651 is unable to determine the launch surface, the launch execution unit 653 launches the program in the launch mode notified by the launch mode determination unit 652.

[0029] In this way, if an update of a program stored in the program storage unit 64 fails, the startup processing unit 65 starts the program in a startup mode corresponding to the update reason 22 included in the received update data 20. This allows the in-vehicle device 6 to avoid a situation in which the program is always started in a degraded mode even if the update reason 22 is not a relatively high-risk reason. For example, if the update reason 22 is to address a defect in some of the program's functions, the in-vehicle device 6 can start the program in a limited-function mode, as shown in FIG. 2. Therefore, the in-vehicle device 6 can minimize the possibility of the vehicle 3 becoming inoperable even if a program update fails.

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

[0031] In S101, if 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, upon receiving the program update notification, the gateway device 5 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, upon receiving the request to transmit 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, and transmits the request to the in-vehicle device 6 together with the update data 20.

[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 to update 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 failure 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 the battery power failure occurs, there is a possibility that some of the launch surface determination information will be lost.

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

[0040] In S110, the in-vehicle device 6 determines whether or not it is possible to determine the startup surface of the program storage unit 64. If the in-vehicle device 6 is able to determine the startup surface of the program storage unit 64, the in-vehicle device 6 proceeds to S111. If the in-vehicle device 6 is unable to determine the startup surface of the program storage unit 64, the in-vehicle device 6 proceeds to S112.

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

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

[0043] In S113, the 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. If the update reason ID 81 of the read update reason 22 is "0x01", the in-vehicle device 6 proceeds to S114. If the update reason ID 81 of the read update reason 22 is "0x02", the in-vehicle device 6 proceeds to S115. If the update reason ID 81 of the read update reason 22 is "0x03", the in-vehicle device 6 proceeds to S116. Note that if the update reason ID 81 of the read update reason 22 is at least "0x02", the 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, the in-vehicle device 6 starts the program stored in the program storage unit 64 in a degenerate mode. If the update reason 22 read in S112 is to address a security vulnerability of the program stored in the program storage unit 64, starting the program increases the risk of being attacked by exploiting a security hole, for example. Therefore, in this case, the in-vehicle device 6 (startup processing unit 65) starts the program in a degenerate mode that only updates the program. This allows the in-vehicle device 6 to reduce the risk of being attacked by exploiting a security vulnerability.

[0045] In S115, the in-vehicle device 6 starts a program that can be started and is stored in one of the multiple storage surfaces of the program storage unit 64. If 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 one of the multiple storage surfaces of the program storage unit 64 can be started normally. Therefore, in this case, the in-vehicle device 6 (startup processing unit 65) starts a program that can be started and is stored in one of the multiple storage surfaces of the program storage unit 64. This allows the in-vehicle device 6 to avoid a degenerate mode in which the vehicle 3 is likely to fall into an inoperable state even if the program update fails, and can control the vehicle 3 to, for example, perform evacuation driving. Therefore, the in-vehicle device 6 can minimize the possibility of the vehicle 3 falling into an inoperable state even if the program update fails.

[0046] In S116, the in-vehicle device 6 starts up in a function-restricted mode. If the update reason 22 read in S112 is to address a defect in some functions of the program stored in the program storage unit 64, it is highly likely that the vehicle 3 will not become inoperable unless the defective function is executed. Therefore, in this case, the in-vehicle device 6 (startup processing unit 65) starts up the program in a function-restricted mode that restricts the defective function to inoperable. This allows the in-vehicle device 6 to avoid a degenerate mode in which the vehicle 3 is likely to become inoperable even if the program update fails, and can control the vehicle 3 to, for example, perform evacuation driving. Therefore, the in-vehicle device 6 can minimize the possibility of the vehicle 3 becoming inoperable even if the program update fails.

[0047] When activating a program stored in the program storage unit 64 in a function-restricted mode, the in-vehicle device 6 restricts defective functions by performing a function determination process to determine 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 component defining each function of the program can be executed. The conditions under which the function determination unit 66 determines whether the program can be executed may be predetermined for each component. The function determination unit 66 may be incorporated into each program stored in the program storage unit 64, as shown in FIG. 1 . 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.

[0049] In S201, the in-vehicle device 6 determines whether a target function (hereinafter also referred to as "target function"), among multiple functions constituting a program stored in the program storage unit 64, for which execution feasibility is to be determined, is a defective function. If the target function is a defective function, the in-vehicle device 6 proceeds to S202. If the target function is not a defective function, the in-vehicle device 6 proceeds to S203.

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

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

[0052] In S204, the in-vehicle device 6 determines whether or not the execution possibility of all target functions has been determined. If the execution possibility of all target functions has not been determined, the in-vehicle device 6 proceeds to S201. If the execution possibility of all target functions has been determined, the in-vehicle device 6 ends this process shown in FIG.

[0053] This allows the in-vehicle device 6 to use a relatively simple method to disable some defective functions while still allowing non-defective functions to be executed normally. Therefore, the in-vehicle device 6 can easily avoid the degenerate mode, and therefore can easily reduce the likelihood of the vehicle 3 becoming inoperable even when a program update fails.

[0054] 2 is created by collecting update reasons 22 for addressing defects in some program functions into one update reason ID 81 "0x03," but is not limited to this. The update reason table 8 may be created by subdividing update reasons 22 for addressing defects in some program functions by program function, and associating each with an update reason ID 81 and a startup mode 83.

[0055] [Embodiment 2] A program update system 1 according to the second embodiment will be described with reference to Fig. 5. In the program update system 1 according to the second embodiment, the description of the same configuration and operation as those according to the first embodiment will be omitted. FIG. 5 is a diagram showing the configuration of a program updating system 1 according to the second embodiment.

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

[0057] As in the first embodiment, when an update of a program stored in the program storage unit 64 fails, the in-vehicle device 6 of the second embodiment starts the program in a startup mode corresponding to the update reason 22 included in the received update data 20. This makes it possible for the in-vehicle device 6 of the second embodiment to avoid a situation in which the program is always started in a degenerate mode even when the update reason 22 is not a relatively high-risk reason, as in the first embodiment. Therefore, as in the first embodiment, the in-vehicle device 6 of the second embodiment can minimize the possibility of the vehicle 3 becoming inoperable even when a program update fails.

[0058] [others] The present invention is not limited to the above-described embodiments and includes various modifications. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and the present invention is not necessarily limited to those including all of the described configurations. Furthermore, it is possible to replace part of the configuration of one embodiment with the configuration of another embodiment, or to add the configuration of another embodiment to the configuration of one embodiment. Furthermore, it is possible to add, delete, or replace part of the configuration of each embodiment with other configurations.

[0059] Furthermore, the above-described configurations, functions, processing units, processing means, etc. may be partially or entirely realized by hardware, for example, by designing them as integrated circuits. The above-described configurations, functions, etc. may also be realized by software, in which a processor interprets and executes a program that realizes each function. Information such as the program, tape, and file that realizes each function can be stored in a memory, a recording device such as a hard disk or solid state drive (SSD), or a recording medium such as an IC card, SD card, or DVD.

[0060] In addition, the control lines and information lines shown are those that are considered necessary for the explanation, and do not necessarily show all the control lines and information lines in the product. In reality, it can be assumed that almost all components are interconnected. [Explanation of symbols]

[0061] 1...program update system, 11...wireless communication network, 2...server device, 21...update program, 22...reason for update, 3...vehicle, 6...vehicle-mounted 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 the program; an update processing unit that receives an update program and a reason for updating the program and updates the program using the update program; The startup processing unit starts the program in a startup mode corresponding to the reason for the update if the update of the program fails. An in-vehicle device comprising:

2. The in-vehicle device according to claim 1 , wherein the startup processing unit starts the program in a degenerate mode in which only the program is updated, when the reason for the update is to address a security vulnerability of the program.

3. When the reason for the update is to address a defect in a part of the function of the program, the startup processing unit starts the program in a function-restricted mode that restricts the part of the defective function to be inoperable.

2. The in-vehicle device according to claim 1.

4. the program storage unit has a plurality of storage surfaces for storing the programs, The startup processing unit starts the program that is executable and stored in any one of the plurality of storage surfaces when the reason for the update is to improve the function of the program.

2. The in-vehicle device according to claim 1.

5. a vehicle equipped with the on-board device according to claim 1; a server device connected to the vehicle via a wireless communication network and configured to transmit the update program and the reason for update to the vehicle; A program update system comprising:

Images