Update control device, update control system, and update control method

An update control device determines whether or not an update of an update target ECU is to be completed within stop time from when a vehicle temporarily stops until the vehicle starts traveling, when a response indicating that the update can be executed is given from an in-vehicle ECU having dependency with the update target in-vehicle ECU.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a National Stage of International Application No. PCT/JP2018/024899, filed Jun. 29, 2018.

TECHNICAL FIELD

The present invention relates to an update control device, an update control system, and an update control method for controlling an update of a control program of an in-vehicle electronic control unit (hereinafter, referred to as an in-vehicle ECU) mounted on a vehicle.

BACKGROUND ART

In recent years, over the air (OTA) technology for updating a control program of an in-vehicle ECU using wireless communication has been proposed. For example, Patent Literature 1 discloses a control device for predicting time during which a vehicle is parked or stopped and updating a program of an in-vehicle ECU using wireless communication during the predicted time.

CITATION LIST

Patent Literatures

Patent Literature 1: JP 2017-215888 A

SUMMARY OF INVENTION

Technical Problem

In the control device disclosed in Patent Literature 1, an update program is written in an in-vehicle device in a time period in which a vehicle is parked and an engine is stopped. For this reason, when there is an urgent update that needs to be dealt with immediately, it is necessary to interrupt traveling of a vehicle and to park the vehicle temporarily, which is bothersome for a driver and impairs convenience of OTA disadvantageously.

The present invention solves the above problems, and an object of the present invention is to obtain an update control device, an update control system, and an update control method capable of updating an in-vehicle ECU without intentionally parking a vehicle.

Solution To Problem

The update control device according to the present invention includes: a processor to execute a program; and a memory to store the program which, when executed by the processor, performs processes of, inquiring of an in-vehicle electronic control unit (ECU) having dependency with an update target in-vehicle electronic control unit whether or not an update of the update target in-vehicle electronic control unit can be executed; calculating an update time required for updating the update target in-vehicle electronic control unit acquiring a stop time from when a vehicle temporarily stops until the vehicle starts traveling; and determining whether or not the update of the update target in-vehicle electronic control unit is to be completed within the stop time by comparing the update time with the stop time when a response indicating that the update can be executed is confirmed.

Advantageous Effects Of Invention

According to the present invention, when a response indicating that an update can be executed is given from an in-vehicle ECU having dependency with an update target in-vehicle ECU, it is determined whether or not the update of the update target in-vehicle ECU is to be completed within a stop time from when a vehicle temporarily stops until the vehicle starts traveling. As a result, the in-vehicle ECU can be updated within the stop time of the vehicle without intentionally parking the vehicle.

DESCRIPTION OF EMBODIMENTS

Hereinafter, in order to describe the present invention in more detail, embodiments for carrying out the present invention will be described with reference to the attached drawings.

First Embodiment

FIG.1is a block diagram illustrating a configuration of an update control system1according to a first embodiment of the present invention. The update control system1is a system for controlling an update of an update target ECU among ECUs3ato3d(in-vehicle electronic control units) mounted on a vehicle, and includes an update control device2and a stop determining ECU in addition to the ECUs3ato3d.The update control device2receives update data for an update target ECU by wireless communication while a vehicle is traveling, and updates the update target ECU within stop time from when the vehicle temporarily stops due to turning on of a red signal of a traffic light or descent of a crossing gate at a railroad crossing until the vehicle starts traveling. The update data is update data for firmware or software included in the in-vehicle ECU. As an update method, full image update or differential image update is used.

The update control device2has a function of performing wired communication and wireless communication, and has a gateway function for connection to a different network. Here, the wireless communication includes data mobile communication such as LTE or 3G, WiFi, Bluetooth (registered trademark), road-to-vehicle communication, and vehicle-to-vehicle communication. Examples of the wired communication include Ethernet (registered trademark), controller area network (CAN), media oriented systems transport (MOST), and local interconnect network (LIN).

The ECUs3ato3dare electronic control units for controlling various in-vehicle devices mounted on a vehicle. For example, the ECU3ais an ECU for implementing a control system of an accelerator operation, a brake operation, a steering wheel operation, vehicle interior lighting, and headlights, and the ECU3bis an ECU for implementing an advanced driver assistance system (ADAS) using a vehicle exterior camera, a vehicle interior camera, and a corner sensor.

The update control device2inquires of an ECU having dependency with an update target ECU whether or not an update can be executed. When a response indicating that the update can be executed is confirmed, the update control device2determines whether or not the update of the update target ECU is to be completed within the stop time by comparing update time required for completing the update with the stop time. Here, dependency between ECUs is a relationship in which the ECUs communicate with each other, and one ECU performs an arithmetic process using information received from the other ECU.

For example, when the ECU3cis an ECU for calculating a vehicle speed and the ECU3dis an ECU for correcting a current position of a vehicle using the vehicle speed, there is dependency between the ECU3cand the ECU3d.In this case, the ECU3dcorrects the current position of the vehicle using the vehicle speed received from the ECU3c.Therefore, when transmission of a signal of the vehicle speed from the ECU3cis interrupted, it may be erroneously recognized that the ECU3dis in an emergency situation in which a communication line with the ECU3cis broken.

When firmware or software included in an ECU is updated, it is necessary to reset the ECU (stop and restart operation) in order to enable an updated program, and thus it is necessary to interrupt communication that has been performed with another ECU before the update. Therefore, the update control device2inquires of an ECU having dependency with an update target ECU whether or not an update can be executed, and updates the update target ECU when a response indicating that the update can be executed is given. Note that when the update target ECU is updated, communication with an ECU having dependency with the update target ECU is shut down. Therefore, for the ECU having dependency, the inquiry about whether or not the update of the update target ECU can be executed can be regarded as an inquiry about whether or not the update target ECU can be shut down.

By monitoring a traffic light or a railroad crossing in front of a vehicle and a vehicle speed, the stop determining ECU4determines whether or not the vehicle has stopped due to turning on of a red signal of the traffic light or descent of a crossing gate at the railroad crossing.

For example, by controlling a vehicle exterior camera, recognizing a light color of the traffic light or a state of the crossing gate at the railroad crossing from an image capturing an area in front of the vehicle, and recognizing the vehicle speed from a vehicle speed sensor or a brake operation, the stop determining ECU4determines whether or not the vehicle has stopped due to turning on of a red signal of the traffic light or descent of the crossing gate at the railroad crossing. When the stop determining ECU4determines that the vehicle has stopped, the stop determining ECU4transmits a stop state notification indicating this determination result to the update control device2using in-vehicle communication.

FIG.2is a block diagram illustrating a configuration of the update control device2. InFIG.2, the update control device2includes a vehicle exterior communication unit20, an update data storing unit21, a stop state detecting unit22, a dependency storing unit23, a dependency confirming unit24, a time information storing unit25, an update time calculating unit26, an updatability determining unit27, and an in-vehicle communication unit28. The vehicle exterior communication unit20is a communication unit for communicating with an external device by wireless communication, and includes a first communication unit20aand a second communication unit20b.

The first communication unit20ais connected to a wireless network by wireless communication such as LTE or 3G, and acquires update data a from an external device connected to the wireless network. The external device is, for example, a server for managing update data for firmware or software included in an ECU. When the ECU is updated, the server transmits the update data a including information indicating firmware or software as an update target and an update program to the update control device2. The update control device2identifies an update target ECU from among the ECUs3ato3don the basis of the update data a received from the server.

The second communication unit20bis a stop time acquiring unit for acquiring stop time b of the vehicle using road-to-vehicle communication or vehicle-to-vehicle communication. The stop time b is time from when the vehicle temporarily stops until the vehicle starts traveling. For example, the second communication unit20bmay receive the stop time b from a roadside wireless communication device disposed at a traffic light or a railroad crossing by road-to-vehicle communication. Here, the roadside wireless communication device is an external device for managing time during which a red signal of a traffic light is turned on or time during which a crossing gate at a railroad crossing is descending as the stop time b. Note that when the stop time b is acquired by an in-vehicle device mounted on a preceding vehicle traveling in front of the vehicle, the second communication unit20bmay acquire the stop time b from the in-vehicle device of the preceding vehicle by vehicle-to-vehicle communication.

The update data storing unit21is a storage unit for storing the update data a for an update target ECU. The update data a received from the server by the first communication unit20ais stored in the update data storing unit21.

The stop state detecting unit22detects a stop state of the vehicle on the basis of whether or not a stop state notification c has been received from the stop determining ECU4. Here, the stop state of the vehicle is a state in which the vehicle temporarily stops due to turning on of a red signal of a traffic light or descent of a crossing gate at a railroad crossing. The stop state detecting unit22detects whether or not the vehicle is in the stop state on the basis of the stop state notification c received from the stop determining ECU4by the in-vehicle communication unit28, and when the vehicle is in the stop state, the stop state detecting unit22outputs the stop state notification c to the dependency confirming unit24.

The dependency storing unit23stores dependency information d indicating dependency between the ECUs3ato3dconnected to the update control device2. The dependency information d is table information in which pieces of information indicating dependency between the ECUs are associated with the respective ECUs. Examples of the information indicating the dependency between the ECUs include a destination address in communication between the ECUs.

The dependency confirming unit24inquires of an ECU having dependency with an update target ECU among the ECUs3ato3dwhether or not an update of the update target ECU can be executed. For example, the dependency confirming unit24confirms the update target ECU by referring to the update data a stored in the update data storing unit21, and confirms a stop state of the vehicle on the basis of the stop state notification c input from the stop state detecting unit22. The dependency confirming unit24identifies an ECU having dependency with the update target ECU on the basis of the dependency information d stored in the dependency storing unit23. The dependency confirming unit24transmits inquiry information e inquiring of the ECU having dependency with the update target ECU whether or not an update of the update target ECU can be executed using the in-vehicle communication unit28.

The ECU having dependency with the update target ECU transmits response information f with respect to the inquiry information e to the update control device2. The dependency confirming unit24generates response content information g indicating the content of the response information f received by the in-vehicle communication unit28, and outputs the response content information g to the updatability determining unit27. The response content information g is used as a condition for determining updatability by the updatability determining unit27.

The time information storing unit25stores pieces of time information h each including startup time, end time, and a memory writing speed of a corresponding ECU connected to the update control device2, associated with the respective ECUs. Here, when an ECU has an operating system (OS) mounted thereon, the startup time of the ECU and the end time of the ECU include startup time of the OS and the end time of the OS, respectively. The end time also includes communication end time between the ECUs. By referring to the time information h stored in the time information storing unit25and data size a1 of the update data a stored in the update data storing unit21, the update time calculating unit26calculates update time i required for updating the update target ECU.

The updatability determining unit27determines whether or not an update of the update target ECU is to be completed within the stop time b. For example, when the response content information g input from the dependency confirming unit24indicates that the update can be executed, the updatability determining unit27determines whether or not the update of the update target ECU is to be completed within the stop time b by comparing the stop time b acquired by the second communication unit20bwith the update time i calculated by the update time calculating unit26.

The in-vehicle communication unit28communicates with each of the ECUs3ato3dand the stop determining ECU4via wired communication such as CAN. For example, the in-vehicle communication unit28transmits the inquiry information e from the dependency confirming unit24to an ECU having dependency with the update target ECU, and receives response information f from the ECU. In addition, the in-vehicle communication unit28transmits update request j from the updatability determining unit27to the update target ECU, and receives update result information k from the update target ECU.

FIG.3is a block diagram illustrating a configuration of an in-vehicle ECU, and illustrates functional configurations of the ECUs3ato3dillustrated inFIG.1. As illustrated inFIG.3, each of the ECUs3ato3dincludes an in-vehicle communication unit30, a dependency responding unit31, an end confirming unit32, and an update unit34. The in-vehicle communication unit30communicates with another ECU and the update control device2via wired communication such as CAN. The dependency responding unit31generates response information f for inquiry information e received by the in-vehicle communication unit30, and transmits the response information f to the update control device2using the in-vehicle communication unit30.

When an ECU on which the end confirming unit32is mounted is an update target ECU, the end confirming unit32confirms an end of communication with an ECU having dependency. For example, when the end confirming unit32receives input of communication end request1from the update unit34, the end confirming unit32transmits communication end notification m to the ECU having dependency using the in-vehicle communication unit30. When an end confirming unit32included in the ECU having dependency receives the communication end notification m, the end confirming unit32generates response information n indicating whether or not communication with the update target ECU can be ended, and transmits the response information n to the update target ECU using the in-vehicle communication unit30. The end confirming unit32included in the update target ECU receives input of the response information n received by the in-vehicle communication unit30thereof and transmitted from the ECU having dependency, and outputs information o indicating the content of the response information n to the update unit34.

The update data storing unit33is a storage unit for storing update data a for an update target ECU. The update data a may be stored in the update data storing unit33before an update is started due to the update request j.

The update unit34updates firmware or software included in the ECU using the update data a stored in the update data storing unit33. For example, when the in-vehicle communication unit30receives the update request j from the update control device2and the update unit34obtains the information o indicating that communication with the ECU having dependency can be ended from the end confirming unit32, the update unit34performs an update process using the update data a. The update unit34transmits the update result information k indicating a result of the update process to the update control device2using the in-vehicle communication unit30.

Next, a hardware configuration for implementing a function of the update control system1will be described.

Functions of the vehicle exterior communication unit20, the update data storing unit21, the stop state detecting unit22, the dependency storing unit23, the dependency confirming unit24, the time information storing unit25, the update time calculating unit26, the updatability determining unit27, and the in-vehicle communication unit28in the update control device2are implemented by a processing circuit. That is to say, the update control device2includes a processing circuit for executing processes in steps ST1ato ST8adescribed later with reference toFIG.6. The processing circuit may be dedicated hardware or a central processing unit (CPU) for executing a program stored in a memory.

Functions of the in-vehicle communication unit30, the dependency responding unit31, the end confirming unit32, and the update unit34, which are included in each of the ECUs3ato3d,are implemented by a processing circuit. That is to say, each of the ECUs3ato3dincludes a processing circuit for executing processes in steps ST1bto ST7bdescribed later with reference toFIG.11. The processing circuit may be dedicated hardware or a CPU for executing a program stored in a memory.

FIG.4is a block diagram illustrating a hardware configuration in which software for implementing a function of the update control system1is executed. InFIG.4, the update control device2and the ECUs3ato3dare connected to each other by a communication bus5. A vehicle exterior network interface100is an interface (hereinafter referred to as I/F) for communication connection with an out-of-vehicle network. For example, the vehicle exterior network I/F100is a road-to-vehicle I/F for communicating with a roadside wireless communication device disposed on a roadside near a traffic light or a railroad crossing, and is a wireless communication I/F for communication connection with a communication network such as the Internet. Examples of the wireless communication I/F include I/Fs of LTE, 3G, WiFi, and Bluetooth (registered trademark). Information transmitted and received between the first communication unit20aand the second communication unit20billustrated inFIG.2and a device outside a vehicle is relayed by the vehicle exterior network I/F100.

An in-vehicle network I/F101and an in-vehicle network I/F200are I/Fs for performing wired communication between ECUs via an in-vehicle network. Examples of the in-vehicle network I/F101and the in-vehicle network I/F200include I/Fs of CAN, Ethernet (registered trademark), MOST, and LIN. Information transmitted and received between the in-vehicle communication unit28illustrated inFIG.2and the in-vehicle communication unit30illustrated inFIG.3is relayed by the in-vehicle network I/F101and the in-vehicle network I/F200.

When the processing circuit for implementing a function of the update control device2is dedicated hardware, for example, a single circuit, a composite circuit, a programmed processor, a parallel programmed processor, an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a combination thereof corresponds to the processing circuit. Functions of the vehicle exterior communication unit20, the update data storing unit21, the stop state detecting unit22, the dependency storing unit23, the dependency confirming unit24, the time information storing unit25, the update time calculating unit26, the updatability determining unit27, and the in-vehicle communication unit28in the update control device2may be implemented by separate processing circuits, or these functions may be collectively implemented by one processing circuit.

When the processing circuit for implementing a function of each of the ECUs3ato3dis dedicated hardware, for example, a single circuit, a composite circuit, a programmed processor, a parallel programmed processor, an ASIC, an FPGA, or a combination thereof corresponds to the processing circuit. Functions of the in-vehicle communication unit30, the dependency responding unit31, the end confirming unit32, and the update unit34, which are included in each of the ECUs3ato3d,may be implemented by separate processing circuits, or these functions may be collectively implemented by one processing circuit.

When the processing circuit for implementing a function of the update control device2is a processor102illustrated inFIG.4, functions of the vehicle exterior communication unit20, the update data storing unit21, the stop state detecting unit22, the dependency storing unit23, the dependency confirming unit24, the time information storing unit25, the update time calculating unit26, the updatability determining unit27, and the in-vehicle communication unit28in the update control device2are implemented by software, firmware, or a combination of software and firmware. Note that the software or the firmware is described as a program and stored in a memory103.

By reading and executing a program stored in the memory103, the processor102implements functions of the vehicle exterior communication unit20, the update data storing unit21, the stop state detecting unit22, the dependency storing unit23, the dependency confirming unit24, the time information storing unit25, the update time calculating unit26, the updatability determining unit27, and the in-vehicle communication unit28in the update control device2. That is to say, the update control device2includes the memory103for storing a program that causes processes in steps ST1ato ST8aillustrated inFIG.6to be executed as a result when the program is executed by the processor102.

The program causes a computer to execute procedures or methods of the vehicle exterior communication unit20, the update data storing unit21, the stop state detecting unit22, the dependency storing unit23, the dependency confirming unit24, the time information storing unit25, the update time calculating unit26, the updatability determining unit27, and the in-vehicle communication unit28. The memory103may be a computer-readable storage medium storing a program for causing a computer to function as the vehicle exterior communication unit20, the update data storing unit21, the stop state detecting unit22, the dependency storing unit23, the dependency confirming unit24, the time information storing unit25, the update time calculating unit26, the updatability determining unit27, and the in-vehicle communication unit28.

When the processing circuit for implementing a function of each of the ECUs3ato3dis a processor201illustrated inFIG.4, functions of the in-vehicle communication unit30, the dependency responding unit31, the end confirming unit32, and the update unit34, which are included in each of the ECUs3ato3d,are implemented by software, firmware, or a combination of software and firmware. Note that the software or the firmware is described as a program and stored in a memory202.

The processor201implements functions of the in-vehicle communication unit30, the dependency responding unit31, the end confirming unit32, and the update unit34, which are included in each of the ECUs3ato3d,by reading and executing a program stored in the memory202. That is to say, each of the ECUs3ato3dincludes the memory202for storing a program that causes processes in steps ST1bto ST11billustrated inFIG.11to be executed as a result when the program is executed by the processor201.

The program causes a computer to execute procedures or methods of the in-vehicle communication unit30, the dependency responding unit31, the end confirming unit32, and the update unit34. The memory202may be a computer-readable storage medium storing a program for causing a computer to function as the in-vehicle communication unit30, the dependency responding unit31, the end confirming unit32, and the update unit34.

As the memory103, a random access memory (RAM)103aand a read only memory (ROM)103bare used. The RAM103atemporarily stores an execution program executed by the processor102and data required for executing the program. The ROM103bstores the execution program. As the memory103, any one of a nonvolatile or volatile semiconductor memory such as a flash memory, an erasable programmable read only memory (EPROM), or electrically-EPROM (EEPROM), a magnetic disk, a flexible disk, an optical disc, a compact disc, a mini disc, and a DVD may be used.

A RAM202aand a ROM202bare used for the memory202similarly to the memory103. The RAM202atemporarily stores an execution program executed by the processor201and data required for executing the program. The ROM202bstores the execution program and an update target program.

Some of functions of the vehicle exterior communication unit20, the update data storing unit21, the stop state detecting unit22, the dependency storing unit23, the dependency confirming unit24, the time information storing unit25, the update time calculating unit26, the updatability determining unit27, and the in-vehicle communication unit28in the update control device2may be implemented by dedicated hardware, and some of the functions may be implemented by software or firmware.

For example, functions of the vehicle exterior communication unit20and the in-vehicle communication unit28are implemented by a processing circuit which is dedicated hardware, and functions of the update data storing unit21, the stop state detecting unit22, the dependency storing unit23, the dependency confirming unit24, the time information storing unit25, the update time calculating unit26, and the updatability determining unit27are implemented by reading and executing a program stored in the memory103with the processor102. In this way, the processing circuit can implement the above functions by hardware, software, firmware, or a combination thereof. The same applies to the ECUs3ato3d.

Next, the operation will be described.

FIG.5is a flowchart illustrating the operation of the update control system1, and illustrates a case where one of the ECUs3ato3dis an update target ECU. It is assumed that a vehicle temporarily stops due to turning on of a red signal of a traffic light or descent of a crossing gate at a railroad crossing before a process ofFIG.5is executed. At this time, the stop determining ECU4determines that the vehicle is in a stop state, and transmits a stop state notification c to the update control device2.

The stop state detecting unit22confirms whether or not the stop state of the vehicle has been detected on the basis of whether or not a stop state notification c has been received from the stop determining ECU4(step ST1). Here, if a stop state notification c has not been received and thus the stop state of the vehicle has not been detected (step ST1; NO), the process ofFIG.5is ended. Note that a series of processes illustrated inFIG.5is executed every time the vehicle stops due to a traffic light or the like while the update control device2is activated.

If a stop state notification c has been received and thus the stop state of the vehicle has been detected (step ST1; YES), the stop state detecting unit22outputs the stop state notification c to the dependency confirming unit24.

The dependency confirming unit24confirms whether or not there is an update target ECU among the ECU3ato3dconnected to the update control device2and update data a has been downloaded (step ST2). For example, by referring to update data a stored in the update data storing unit21, the dependency confirming unit24confirms whether or not there is an update target ECU among the ECU3ato3dand update data a has been downloaded to the update data storing unit21.

If there is no update target ECU among the ECU3ato3dor update data a has not been downloaded (step ST2; NO), the process ofFIG.5is ended.

Note that in the first embodiment, update data a that enables an update process is data that has been downloaded to the update control device2while the vehicle is traveling.

Meanwhile, if there is an update target ECU among the ECU3ato3dand update data a has been downloaded (step ST2; YES), the dependency confirming unit24and the updatability determining unit27determine whether or not an update of the update target ECU can be executed (step ST3). Note that the updatability determination will be described in detail with reference toFIG.6described later. If the updatability determining unit27determines that an update of the update target ECU cannot be executed (step ST3; NO), the process ofFIG.5is ended.

If the updatability determining unit27determines that an update of the update target ECU can be executed (step ST3; YES), the updatability determining unit27transmits update request to the update target ECU so as to execute an update (step ST4). The update data a may be stored in the update data storing unit33before an update is started due to update request j.

The update target ECU executes a firmware or software update process using the update data a received from the update control device2. Then, the update target ECU transmits update result information k indicating whether or not an update is successful to the update control device2using the in-vehicle communication unit30.

The in-vehicle communication unit28included in the update control device2receives the update result information k from the update target ECU (step ST5). When the update result information k indicates that the update is successful, the update of the update target ECU is completed. Meanwhile, when the update result information k indicates that the update fails, the series of processes inFIG.5is repeatedly executed until the update of the update target ECU is completed.

Next, details of an updatability determination process will be described.

FIG.6is a flowchart illustrating an update control method according to the first embodiment, and illustrates details of step ST3illustrated inFIG.5.

First, the dependency confirming unit24inquires of an ECU having dependency with the update target ECU whether or not an update of the update target ECU can be executed (step ST1a). For example, the dependency confirming unit24identifies all the ECUs having dependency with the update target ECU on the basis of dependency information d stored in the dependency storing unit23.

FIG.7is a diagram illustrating an example of the dependency information d. In dependency information d illustrated inFIG.7, an address of an ECU in in-vehicle communication between ECUs is set as information indicating dependency with an update target ECU. When the in-vehicle communication is Ethernet (registered trademark), the address of an ECU corresponds to the internet protocol (IP) address and the port number of the ECU. When the in-vehicle communication is CAN, the address of an ECU corresponds to the CAN-ID received by an ECU at a communication connection destination.

For example, when the update target ECU is the ECU3a,the ECU3ahas dependency (1) for performing in-vehicle communication with the ECU3cas illustrated inFIG.7. Meanwhile, when the update target ECU is the ECU3c,the ECU3chas three dependencies of dependency (1), dependency (2), and dependency (3). That is to say, the update target ECU3chas dependency (1) for performing in-vehicle communication with the ECU3a,dependency (2) for performing in-vehicle communication with the ECU3b,and dependency (3) for performing in-vehicle communication with the ECU3d.

For example, when the update target ECU is the ECU3b,by referring to the dependency information d illustrated inFIG.7, the dependency confirming unit24identifies the ECU3cand ECU3dhaving dependency with the ECU3bfrom among the ECU3a,ECU3c,and ECU3d.Subsequently, the dependency confirming unit24outputs inquiry information e to the in-vehicle communication unit28, and thereby transmits the inquiry information e to the ECU3cand the ECU3dhaving dependency with the update target ECU3b.When a plurality of ECUs is an inquiry target, the in-vehicle communication unit28may deliver the inquiry information e by broadcasting.

FIG.8is an explanatory diagram illustrating a process of confirming dependency of an ECU in the first embodiment. Description will be made by assuming that the ECU3ais an update target and the ECU3chas dependency with the ECU3ainFIG.8. In addition, it is assumed that the vehicle temporarily stops due to a red signal of a traffic light6, and update data a has been downloaded from a server7to the update control device2.

The dependency confirming unit24included in the update control device2transmits information inquiring whether or not there is a problem in an update to the update target ECU3ausing the in-vehicle communication unit28(information communication process (1)). When the above information is received by the in-vehicle communication unit30, the dependency responding unit31included in the update target ECU3atransmits response information f to the update control device2using the in-vehicle communication unit30(information communication process (2)).

At this time, the dependency responding unit31manages communication between the update target ECU3aand the ECU3chaving dependency therewith in communication states (A) to (C), and determines the content of the response information f on the basis of a current communication state. The communication state (A) is a state in which the ECU3ais not communicating. The communication state (B) is a state in which the ECU3aperiodically communicates with the ECU3c.In the communication state (B), the ECU3adoes not communicate with the ECU3cexcept in a communication cycle. In the communication state (C), the ECU3aand the ECU3care currently communicating with each other, and are performing processes using information obtained by the communication. The dependency responding unit31included in the update target ECU3aidentifies a state corresponding to a current communication state from among the communication states (A) to (C), and transmits response information f indicating the identified communication state to the update control device2using the in-vehicle communication unit30(information communication process (2)).

The dependency confirming unit24included in the update control device2transmits inquiry information e to the ECU3chaving dependency with the update target ECU3ausing the in-vehicle communication unit28(information communication process (1a)). When the inquiry information e is received by the in-vehicle communication unit30, the dependency responding unit31included in the ECU3ctransmits response information f to the update control device2using the in-vehicle communication unit30(information communication process (2a)). At this time, the dependency responding unit31included in the ECU3cmanages communication with the update target ECU3ain the communication states (A) to (C). The dependency responding unit31included in the ECU3cidentifies a state corresponding to a current communication state from among the communication states (A) to (C), and transmits response information f indicating the identified communication state to the update control device2using the in-vehicle communication unit30(information communication process (2a)).

Here, return to the description ofFIG.6.

The dependency confirming unit24confirms whether or not responses each indicating that an update can be executed have been given from all the ECUs having dependency with the update target ECU on the basis of the response information f (step ST2a). For example, when a communication state indicated by the response information f is the communication state (A) or the communication state (B), the dependency confirming unit24determines that the response information f indicates that an update can be executed, and outputs response content information g indicating that an update can be executed to the updatability determining unit27. Meanwhile, when the communication state indicated by the response information f is the communication state (C), the dependency confirming unit24determines that the response information f indicates that an update cannot be executed, and outputs response content information g indicating that an update cannot be executed to the updatability determining unit27.

If all the ECUs having dependency with the update target ECU have given responses each indicating that an update can be executed (step ST2a;YES), the updatability determining unit27instructs the update time calculating unit26to calculate update time i. When receiving the instruction from the updatability determining unit27, the update time calculating unit26calculates the update time i of the update target ECU (step ST3a). For example, by referring to time information h stored in the time information storing unit25and data size a1 of update data a stored in the update data storing unit21, the update time calculating unit26calculates the update time i required for updating the update target ECU.

FIG.9is a diagram illustrating an example of the time information h in the first embodiment. Time information h illustrated inFIG.9is table information in which startup time (milliseconds) of an ECU, a writing speed (milliseconds/byte) of the ROM202b,end time (milliseconds) of operation of the ECU, the number of times of startup of the ECU and the number of times of end of the ECU (times), and spare time (milliseconds) are associated with the ECU. Note that the ROM202bstores an execution program and an update program.

The update time calculating unit26calculates the update time i in accordance with the following formula (1) using the time information h and the data size a1 of the update data a. Note that, in the following formula (1), A represents startup time of the update target ECU, B represents the number of times of startup of the update target ECU, and C represents a writing speed of the ROM202bincluded in the update target ECU. D represents the data size a1 of the update data a. E represents end time of operation of the update target ECU, F represents the number of times of end of the update target ECU, and G represents spare time.
Update time (milliseconds)=(A×B)+(C×D)+(E×F)+G(1)

For example, when the update target is the ECU3a,using the time information h illustrated inFIG.9and the data size a1 of the update data a, update time i of the ECU3ais calculated as follows in accordance with the above formula (1). Note that in the above formula (1), each of startup time A of an ECU and end time E thereof may be average time obtained by repeating startup and end of the ECU several tens of times. The spare time G is time as a margin for surely completing an update of an ECU, and is time during which a recovery to return the program to a previous version or execute the update again can be performed even if the update fails.

Update time (milliseconds) of ECU3a=100+(0.001×a1)+500+2000

The number B of times of startup of an ECU and the number F of times of end thereof are the number of times of startup and the number of times of end affected by reset of the ECU executed by updating firmware or software included in the ECU, respectively, and vary depending on a configuration of a memory area of the ROM202b.

FIG.10Ais a diagram illustrating a configuration of a memory area of the ROM202bincluded in an update target ECU.FIG.10Bis a diagram illustrating another configuration of the memory area of the ROM202bincluded in the update target ECU. InFIGS.10A and10B, the update target ECU is assumed to be the ECU3a.

InFIG.10A, the ROM202bincludes a memory area21a,a memory area SW(1), and a memory area SW(2) in addition to a memory area storing a startup flag. The memory area21afunctions as the update data storing unit33and stores update data a. The memory area SW(1) includes a memory area34aand a memory area35a.

Here, the memory area34astores a program for implementing a function of the update unit34. The memory area35astores a program for implementing update target software other than the update unit34.

The memory area SW(2) includes a memory area34band a memory area35b. The memory area34bstores a program for implementing a function of the update unit34, and the memory area35bstores a program for implementing update target software other than the update unit34. InFIG.10A, since a startup label “1” is set at a start address of the memory area SW(1), the processor201executes a program stored in the memory area SW(1). That is to say, when the ECU3ais updated, the program stored in the memory area34ais executed by the processor201, and thereby the update unit34is starting up.

The update unit34updates a program stored in the memory area SW(2) using the update data a read from the memory area21a.Thereafter, a startup label “2” is set at a start address of the updated memory area SW(2), and then the ECU3ais reset in order to enable the updated program stored in the memory area SW(2). That is to say, operation of the ECU3ais ended and the ECU3ais restarted. At this time, the number of times of end of the ECU3ais one, and the number of times of startup of the ECU3ais one. When the ECU3arestarts, the program stored in the memory area34bis executed by the processor201, and thereby the update unit34starts up.

Meanwhile, the ROM202billustrated inFIG.10Bincludes a memory area21a,a memory area34c,and a memory area35cin addition to a memory area storing a startup flag. The memory area21afunctions as the update data storing unit33and stores update data a. The memory area34cstores a program for implementing a function of the update unit34, and the memory area35cstores a program for implementing update target software other than the update unit34.

Since a startup label “1” is set at a start address of the memory area35c,the processor201executes the program stored in the memory area35c.That is to say, when the ECU3ais updated, a program other than the update unit34is executed by the processor201. Therefore, a startup label “2” is set at a start address of the memory area34c,and then the ECU3ais reset. As a result, operation of the ECU3ais ended and the ECU3ais restarted. Resetting the ECU3acauses the update unit34to start up.

Next, the update unit34updates the program stored in the memory area35cusing the update data a read from the memory area21a.Thereafter, a startup label “1” is set at a start address of the updated memory area35c,and then the ECU3ais reset in order to enable the updated program stored in the memory area35c.As a result, operation of the ECU3ais ended and the ECU3ais restarted. As a result, the program stored in the memory area35cstarts up. When a program stored in the ROM202bhaving a configuration of a memory area illustrated inFIG.10Bis updated in this way, the number of times of startup of the ECU3ais two, and the number of times of end of the ECU3ais two.

The second communication unit20bincluded in the vehicle exterior communication unit20acquires stop time b (step ST4a). For example, the second communication unit20breceives the stop time b from a roadside wireless communication device disposed at a traffic light or a railroad crossing. Note that the stop time b is time during which a red signal of the traffic light is turned on or time during which a crossing gate at the railroad crossing is descending, and is time from when the vehicle temporarily stops due to turning on of the red signal of the traffic light or descent of the crossing gate at the railroad crossing until the vehicle starts traveling. The stop time b acquired by the second communication unit20bis output to the updatability determining unit27.

By comparing the stop time b input from the second communication unit20bwith the update time i calculated by the update time calculating unit26(step ST5a), the updatability determining unit27determines whether or not the stop time b is longer than the update time i (step ST6a). If it is determined that the stop time b is equal to or shorter than the update time i (step ST6a;NO), or if any one of the ECUs having dependency with the update target ECU has given a response indicating that an update cannot be executed as a result of an inquiry from the dependency confirming unit24(step ST2a;NO), the updatability determining unit27determines that an update of the update target ECU cannot be executed (step ST7a). Thereafter, the process ofFIG.6is ended.

Meanwhile, if it is determined that the stop time b is longer than the update time i (step ST6a;YES), the updatability determining unit27determines that an update of the update target ECU can be executed (step ST8a). Thereafter, the updatability determining unit27transmits update request j to the update target ECU so as to execute an update, using the in-vehicle communication unit28, and ends the process ofFIG.6.

Next, details of an update process in an ECU will be described.

FIG.11is a flowchart illustrating a process of updating an update target ECU in the first embodiment.FIG.12is an explanatory diagram illustrating a process from an end of communication between ECUs to notification of an update result. Hereinafter, description will be made by assuming that among the ECUs3ato3dconnected to the update control device2, the ECU3ais an update target, and the ECU3chas dependency with the ECU3a.

The updatability determining unit27included in the update control device2transmits update request j to the update target ECU3aso as to execute an update, using the in-vehicle communication unit28(information communication process (1) illustrated inFIG.12). The in-vehicle communication unit30included in the ECU3areceives the update request j from the update control device2(step ST1b). The update request j received by the in-vehicle communication unit30is output to the update unit34. When the update unit34receives input of the update request j, the update unit34outputs communication end request1to the end confirming unit32.

When the end confirming unit32included in the ECU3areceives input of the communication end request1from the update unit34, the end confirming unit32confirms whether or not there is an ECU having dependency with the update target ECU3aamong the ECUs3bto3dconnected to the update control device2(step ST2b).

For example, the end confirming unit32confirms whether or not there is dependency between the ECU3aand a different ECU on the basis of a communication state between the ECU3aand the different ECU.

Note that when the update request j is received from the update control device2, if the communication state of the ECU3ais the communication state (A) (not communicating with an ECU), the process of step ST3bmay be omitted.

Here, if there is an ECU having dependency with the update target ECU3a(step ST2b;YES), the end confirming unit32transmits communication end notification m to the ECU having dependency with the update target ECU3ausing the in-vehicle communication unit30in order to confirm whether or not there is a problem even if the update target ECU3ais shut down at the current point in time (step ST3b). In the example ofFIG.12, communication end notification m is transmitted from the ECU3ato the ECU3c(information communication process (2) inFIG.12).

The end confirming unit32included in the ECU3ccontrols, when the in-vehicle communication unit30thereof receives the communication end notification m, the in-vehicle communication unit30in such a manner that the communication state with the ECU3atransitions to the above-described communication state (A) (not communicating). For example, when the ECU3cand the ECU3aare communicating with each other in the communication state (B) (periodic communication), a timer for periodic communication is stopped, and thereby the communication with the ECU3ais interrupted. When the communication end notification m from the ECU3ais received, the end confirming unit32included in the ECU3cmay control the in-vehicle communication unit30in such a manner that communication with the ECU3ais not performed until an update of the ECU3ais completed.

When the communication state with the update target ECU3ahas transitioned to a communication state that does not cause a problem even if the communication with the update target ECU3ais ended, the end confirming unit32included in the ECU3ctransmits response information n indicating that the communication with the update target ECU3acan be ended to the update target ECU3ausing the in-vehicle communication unit30(information communication process (3) inFIG.12).

The end confirming unit32included in the update target ECU3aconfirms whether or not responses have been given from all the ECUs having dependency with the ECU3a(step ST4b). Here, the end confirming unit32confirms whether or not response information n indicating that the communication with the ECU3acan be ended has been received from all the ECUs having dependency. The end confirming unit32outputs information o indicating the content of the response information n to the update unit34. The update unit34determines whether or not the response information n indicating that the communication with the update target ECU3acan be ended has been received on the basis of the information o transmitted from the end confirming unit32.

If the response information n indicating that the communication with the ECU3acan be ended has been received from all the ECUs having dependency (step ST4b; YES), or if there is no ECU having dependency with the update target ECU (step ST2b; NO), the update unit34starts an update (step ST5b). As a result, an update of the firmware or software included in the ECU3ais started.

Meanwhile, if response information n indicating that the communication with the ECU3acannot be ended is received from any one of the ECUs having dependency (step ST4b;NO), the update unit34determines that an update fails (step ST6b).

When the process of step ST5bor the process of step ST6bis completed, the update unit34notifies the update control device2of an update result (step ST7b). For example, the update unit34transmits update result information k indicating a result of the update process to the update control device2using the in-vehicle communication unit30(information communication process (4) inFIG.12).

Next, details of a process of downloading update data will be described.

FIG.13is an explanatory diagram illustrating a process of downloading update data in the first embodiment.

The first communication unit20aincluded in the update control device2downloads update data a from the server7for managing the update data using mobile data communication while the vehicle is traveling. The update data a downloaded by the first communication unit20ais temporarily stored in the update data storing unit21included in the update control device2as illustrated inFIG.13.

A reason why the update data a is temporarily stored in the update data storing unit21is that wireless communication between the server7and the first communication unit20ais more unstable than wired communication, and furthermore, when a plurality of ECUs is update targets, the data size of the update data a is large in response thereto, and thus it is necessary to temporarily store the data.

When download of the update data a by the first communication unit20ais completed, the data size is imparted to the update data a stored in the update data storing unit21, and the update data a is transmitted to an update target ECU by the in-vehicle communication unit28. InFIG.13, the update target ECU is the ECU3a.

When the in-vehicle communication unit30included in the ECU3areceives the update data a, the in-vehicle communication unit30stores the update data a in the update data storing unit33. The update unit34updates firmware or software included in the ECU3ausing the update data a stored in the update data storing unit33.

As described above, when a response indicating that an update can be executed is given from an ECU having dependency with an update target ECU, the update control device2according to the first embodiment determines whether or not the update of the update target ECU is to be completed within stop time b from when a vehicle temporarily stops until the vehicle starts traveling.

For example, when it is determined that the update of the ECU is to be completed within stop time b from when the vehicle stops due to a red signal of a traffic light or descent of a crossing gate at a railroad crossing until the vehicle starts traveling, the update of the ECU is executed. As a result, the ECU can be updated without intentionally parking the vehicle.

In the update control device2according to the first embodiment, the second communication unit20bacquires the stop time b from an external device. For example, the second communication unit20bacquires time during which a red signal of a traffic light is turned on or time during which a crossing gate at a railroad crossing is descending as the stop time b. As a result, the update control device2can obtain accurate stop time at the traffic light or the railroad crossing.

The update control device2according to the first embodiment includes the dependency storing unit23for storing the dependency information d indicating dependency between ECUs. The dependency confirming unit24inquires of an ECU whose dependency with an update target ECU has been confirmed on the basis of the dependency information d stored in the dependency storing unit23whether or not an update of the update target ECU can be executed. As a result, the update control device2can accurately recognize an ECU having dependency with the update target ECU and can inquire of the ECU having dependency with the update target ECU whether or not an update of the update target ECU can be executed.

In the update control device2according to the first embodiment, the update time calculating unit26calculates update time i on the basis of a time required for shutting down, starting up, and memory rewriting of the update target ECU. As a result, the update control device2can calculate accurate update time i.

The update control system1according to the first embodiment has a configuration illustrated inFIG.1and therefore can update an ECU without intentionally parking a vehicle.

In the update control method according to the first embodiment, since a series of processes illustrated inFIG.6is executed, an ECU can be updated without intentionally parking a vehicle similarly to the above.

Second Embodiment

In a second embodiment, when a plurality of ECUs is update targets, update order is determined depending on update priority, and the update is performed for each of the ECUs in the determined order. When an update of one ECU is completed and updates of the other ECUs are not executed, updatability determination is executed for an update having a high priority. The priority is a value imparted depending on urgency of an update. As an update has a higher priority, the update is more urgent and needs to be dealt with more quickly.

Note that configurations of an update control device according to the second embodiment and an update control system according to the second embodiment are the same as those of the first embodiment. Therefore, in the following description,FIGS.1,2and3will be referred to for components of the second embodiment.

FIG.14is a flowchart illustrating an update control method according to the second embodiment of the present invention.

Hereinafter, it is assumed that all of the ECUs3ato3dare update target ECUs. Furthermore, it is assumed that a vehicle temporarily stops due to turning on of a red signal of a traffic light or descent of a crossing gate at a railroad crossing before a process ofFIG.14is executed. At this time, the stop determining ECU4determines that the vehicle is in a stop state, and transmits a stop state notification c to the update control device2.

The stop state detecting unit22confirms whether or not the stop state of the vehicle has been detected on the basis of whether or not a stop state notification c has been received from the stop determining ECU4(step ST1c).

If a stop state notification c has not been received and thus the stop state of the vehicle has not been detected (step ST1c;NO), the process ofFIG.14is ended. Note that a series of processes illustrated inFIG.14is executed periodically while the update control device2is activated.

If a stop state notification c has been received and thus the stop state of the vehicle has been detected (step ST1c;YES), the stop state detecting unit22outputs the stop state notification c to the dependency confirming unit24.

The dependency confirming unit24confirms whether or not there is an update target ECU among the ECU3ato3dconnected to the update control device2and whether or not update data a has been downloaded (step ST2c). If there is no update target ECU or update data a has not been downloaded (step ST2c;NO), the process ofFIG.14is ended.

Meanwhile, if there is an update target ECU among the ECU3ato3dand update data a has been downloaded (step ST2c;YES), the dependency confirming unit24determines whether or not there is a plurality of update target ECUs (step ST3c). Here, if the number of update target ECUs is one (step ST3c;NO), the process proceeds to step ST5c.

If there is a plurality of update target ECUs (step ST3c;YES), the dependency confirming unit24notifies the updatability determining unit27of the presence of the plurality of update target ECUs. When the updatability determining unit27receives the above notification from the dependency confirming unit24, the updatability determining unit27determines an ECU to be updated from among the plurality of update target ECUs (step ST4c). For example, the updatability determining unit27extracts priority imparted to each update from the update data a stored in the update data storing unit21, and determines that an ECU having the highest update priority is an ECU to be updated.

The dependency confirming unit24and the updatability determining unit27determine whether or not an update of the ECU determined in step ST4ccan be executed (step ST5c). Note that this updatability determination is the same as the process described with reference toFIG.6in the first embodiment. If the updatability determining unit27determines that the update of the update target ECU cannot be executed (step ST5c;NO), the process proceeds to step ST8c.

If the updatability determining unit27determines that the update of the update target ECU can be executed (step ST5c;YES), the updatability determining unit27transmits update request to the update target ECU so as to execute the update (step ST6c). For example, the updatability determining unit27transmits update request j to the update target ECU and transmits the update data a temporarily stored in the update data storing unit21to the update target ECU using the in-vehicle communication unit28.

The update target ECU executes a firmware or software update process using the update data a received from the update control device2. Then, the update target ECU transmits update result information k indicating whether or not an update is successful to the update control device2using the in-vehicle communication unit30.

The in-vehicle communication unit28included in the update control device2receives the update result information k from the update target ECU (step ST7c).

The updatability determining unit27determines whether or not there is an update target ECU for which an update process has not been executed among the plurality of update target ECUs determined in step ST3c,and whether or not there is time required for completing the update in current stop time b (step ST8c). For example, the updatability determining unit27determines whether or not there is an update target ECU for which an update process has not been executed, and whether or not difference time obtained by subtracting time required for the last update (update time i in the last update) from stop time b is longer than a threshold value.

If there is no update target ECU for which an update process has not been executed or there is no stop time b required for completing the update (step ST8c;NO), the process ofFIG.14is ended. Note that even if it is determined that an update of an ECU having the highest update priority cannot be executed in step ST5c,by performing the determination of step ST8c,it is possible to determine whether or not an update of an ECU can be executed in descending order of update priority.

Meanwhile, if there is an update target ECU for which an update process has not been executed, and there is time required for completing the update in current stop time b (step ST8c;YES), the updatability determining unit27returns to step ST3c. Here, for example, the updatability determining unit27compares update time i of an ECU having the highest update priority with difference time obtained by subtracting time required for the last update (update time i in the last update) from stop time b. Then, the updatability determining unit27determines that an update can be executed when the difference time is longer than the update time i, and determines that an update cannot be executed when the difference time is equal to or shorter than the update time.

As described above, in the update control device2according to the second embodiment, when there is a plurality of update target ECUs, the updatability determining unit27performs, in order of update priority, determinations each of which is a determination as to whether or not an update of a corresponding one of the update target ECUs is to be completed within stop time. As a result, even if a plurality of updates is requested simultaneously, an important update having a high priority is executed first. Furthermore, it is also possible to execute a plurality of updates within stop time b.

Third Embodiment

In a third embodiment, when a plurality of ECUs is to be updated simultaneously or in update order, by comparing the total time obtained by summing up update times of the plurality of ECUs with stop time, it is determined whether or not an update can be executed. Note that configurations of an update control device according to the third embodiment and an update control system according to the third embodiment are the same as those of the first embodiment. Therefore, in the following description,FIGS.1,2and3will be referred to for components of the third embodiment.

Note that when pieces of firmware or pieces of software included in a plurality of ECUs are updated simultaneously or in update order, it is necessary to make update versions thereof consistent.

For example, consider a case where the ECU3aand the ECU3coperate with software of the same version. In this case, a version 1.0.0 of software included in the ECU3acan be updated to a version 2.0.0, and furthermore, a version 1.0.0 of software included in the ECU3ccan be updated to a version 2.0.0. However, it is not possible to update only the version of software included in the ECU3cto a version 2.0.0 while the version 1.0.0 of software included in the ECU3ais not updated.

FIG.15is a flowchart illustrating an update control method according to the third embodiment of the present invention, and illustrates a series of processes corresponding to the process of step ST5cofFIG.14.

In a repeated loop for the number of times corresponding to the number of update target ECUs, the dependency confirming unit24inquires of an ECU having dependency with any one of the update target ECUs whether or not an update of the update target ECU can be executed (step ST1d). For example, the dependency confirming unit24identifies, for each of the update target ECUs, all the ECUs having dependency with the update target ECU on the basis of dependency information d stored in the dependency storing unit23.

When, for each of the update target ECUs, an inquiry to an ECU having dependency with the update target ECU about whether or not an update can be executed is made, the dependency confirming unit24confirms, for each of the update target ECUs, whether or not responses each indicating that an update can be executed have been given from all the ECUs having dependency with the update target ECU on the basis of response information f received from the ECUs having dependency (step ST2d).

For example, when the response information f indicates that an update can be executed, the dependency confirming unit24outputs response content information g indicating that an update can be executed to the updatability determining unit27. Meanwhile, when the response information f indicates that an update cannot be executed, the dependency confirming unit24outputs response content information g indicating that an update cannot be executed to the updatability determining unit27.

If responses each indicating that an update can be executed have been given from all the ECUs having dependency with the update target ECU (step ST2d;YES), the update time calculating unit26proceeds to a repeated loop for the number of times corresponding to the number of the update target ECUs. In this repeated loop, the update time calculating unit26calculates update time i for each of the update target ECUs (step ST3d). For example, by referring to time information h stored in the time information storing unit25and data size a1 of update data a for each update, stored in the update data storing unit21, the update time calculating unit26calculates update time i required for each of updates of the update target ECUs.

The second communication unit20bincluded in the vehicle exterior communication unit20acquires stop time b (step ST4d). For example, the second communication unit20breceives the stop time b from a roadside wireless communication device disposed at a traffic light or a railroad crossing. The stop time b acquired by the second communication unit20bis output to the updatability determining unit27.

By comparing the stop time b input from the second communication unit20bwith the total time obtained by summing up update times i each of which is calculated for the corresponding update target ECU by the update time calculating unit26(step ST5d), the updatability determining unit27determines whether or not the stop time b is longer than the total time (step ST6d). If it is determined that the stop time b is equal to or shorter than the total time (step ST6d;NO), or if any one of ECUs having dependency with the update target ECUs has given a response indicating that an update cannot be executed as a result of an inquiry from the dependency confirming unit24(step ST2d;NO), the updatability determining unit27determines that updates of the update target ECUs cannot be executed (step ST7d).

If it is determined that the stop time b is longer than the total time (step ST6d; YES), the updatability determining unit27determines that updates of the update target ECUs can be executed (step ST8d).

Thereafter, the updatability determining unit27transmits update request j to the update target ECUs so as to execute updates, using the in-vehicle communication unit28, and ends the process ofFIG.14.

Meanwhile, if it is determined that updates of the update target ECUs cannot be executed in step ST7d,the updatability determining unit27excludes an ECU for which it has been determined that an update cannot be executed and a plurality of ECUs having an update order from the update target ECUs (step ST9d).

In the process of step ST8cofFIG.14, the updatability determining unit27determines an update target ECU that has not been updated regardless of the update order. Therefore, when the process ofFIG.15is completed and the process returns to the process ofFIG.14, the update order is not considered in step ST8c.For this reason, the updatability determining unit27excludes an ECU for which it has been determined that an update cannot be executed and a plurality of ECUs having an update order from the update target ECUs.

Note that the case has been described in which by comparing the total time obtained by summing up update times i each of which is calculated for the corresponding ECU with the stop time b, it is determined whether or not updates of the update target ECUs are to be completed within the stop time b. However, the update control device2according to the third embodiment is not limited thereto.

For example, when there is a plurality of update target ECUs and updates thereof are to be performed in parallel, the updatability determining unit27may determine whether or not the updates of the plurality of update target ECUs are to be completed within stop time b, by comparing the longest update time i among the update times i calculated for the respective ECUs by the update time calculating unit26with the stop time b. As a result, even when a plurality of updates is performed in parallel, the ECUs can be updated without intentionally parking a vehicle.

As described above, in the update control device2according to the third embodiment, when there is a plurality of update target ECUs, the updatability determining unit27determines whether or not updates of the plurality of update target ECUs are to be completed within stop time b, by calculating the total time of update times i calculated for the respective ECUs by the update time calculating unit26and comparing the total time with the stop time b. As a result, even if there is a combination of a plurality of updates, the ECUs can be updated without intentionally parking a vehicle.

Note that the present invention is not limited to the above embodiments, and the embodiments can be freely combined with one another, any component in the embodiments can be modified, or any component in the embodiments can be omitted within the scope of the present invention.

INDUSTRIAL APPLICABILITY

The update control device according to the present invention can update an in-vehicle ECU without intentionally parking a vehicle, and therefore can be used in an update control system for updating the in-vehicle ECU by OTA.

REFERENCE SIGNS LIST