JP2018202940A - Software update system - Google Patents

Abstract

To provide a software update system capable of suppressing an increase in power consumption during software update.SOLUTION: A software update system includes: an update management device for receiving updated software wirelessly transmitted from the outside of a vehicle; and a plurality of ECUs 3 communicably connected with the update management device. The plurality of ECUs 3 each have a storage unit 31 for storing a prescribed data frame, and a data frame determination unit 32 for determining, upon receiving a signal, whether the signal conforms or not to the prescribed data frame stored in the storage unit 31. When determining that the signal conforms to the prescribed data frame stored in the storage unit 31 in the case where the other functions of its own ECU 3 are in a sleep state, the data frame determination unit 32 activates at least some of the other functions by releasing them from the sleep state. Otherwise, the data frame determination unit 32 retains the sleep state.SELECTED DRAWING: Figure 3

Description

  The present invention relates to a software update system for executing software update of an in-vehicle device.

  2. Description of the Related Art Conventionally, a software update system has been developed in which a vehicle receives update software transmitted from the outside of the vehicle by wireless communication and updates ECU software of the in-vehicle device. A software update system is described in, for example, Japanese Patent Application Laid-Open No. 2010-167997. In this software update system, when the ignition is on, the vehicle update management device receives the update software wirelessly, and the update software is stored in the memory. Then, the update target ECU is notified that there is update software, and the update target ECU masks the power-down sequence due to the ignition. When the ignition is turned off, the ECU that is not the update target shifts to the sleep state, and the software update is performed in the update target ECU that is maintained in the activated state by the mask. Thereby, the power consumption of the vehicle at the time of update can be reduced.

JP 2010-167997 A

  However, the software update system has room for improvement from the viewpoint of power consumption. While software update (for example, transmission of update software from the update management apparatus to the update target ECU) is being executed between the update management apparatus and the update target ECU, for example, in-vehicle communication such as CAN communication is used. Yes. If the ECU is equipped with a function to detect the start of in-vehicle communication and wake up, the ECU that is not subject to update may also receive a communication pulse in the in-vehicle communication, thereby starting the ECU that is not subject to update There is. If an ECU that is not an update target is activated at the time of updating, the power consumption increases accordingly.

  The present invention has been made in view of such circumstances, and an object thereof is to provide a software update system capable of suppressing an increase in power consumption during software update.

  The software update system of the present invention is a software update system installed in a vehicle that executes software update of a plurality of in-vehicle devices, and receives an update software transmitted from the outside of the vehicle by radio. And a plurality of ECUs connected to the update management device so as to be communicable and controlling the different on-vehicle devices, each of the plurality of ECUs storing a predetermined data frame, and a signal A data frame determination unit that determines whether or not the signal matches the predetermined data frame stored in the storage unit, and the data frame determination unit When other functions are in a sleep state, the signal conforms to the predetermined data frame stored in the storage unit A determination unit that determines whether or not the determination unit is compatible, a cancellation unit that cancels the sleep state and activates at least a part of the other functions, and the determination unit And a maintenance unit that maintains the sleep state when it is determined that they are not suitable.

  According to the present invention, by updating the data frame determination unit in each ECU, the software of the ECU to be updated can be updated without activating other functions even when the ECU not to be updated receives a signal. can do. For example, even when a communication pulse is input to each ECU as update software is transmitted / received via in-vehicle communication, the ECU that is not subject to update and is in a sleep state has predetermined data stored in its storage unit. Unless a signal suitable for the frame is received, the sleep state is maintained without activating other functions. Since the function of the data frame determination unit is a simple comparison of data arrangement, it can be executed with extremely small power. That is, according to the present invention, unnecessary activation of the ECU can be suppressed with small power consumption, and as a result, an increase in power consumption can be suppressed.

It is a block diagram of the software update system of 1st embodiment. It is a hardware block diagram of slave ECU of a first embodiment. It is a block diagram of slave ECU of 1st embodiment. It is a flowchart which shows the flow of the update process of 1st embodiment. It is a flowchart which shows the flow of the update process of 2nd embodiment. It is explanatory drawing for demonstrating the update process of 2nd embodiment.

<First embodiment>
Hereinafter, embodiments of the present invention will be described with reference to the drawings. The software update system 1 according to the first embodiment is a system mounted on a vehicle that executes software updates of a plurality of in-vehicle devices. As shown in FIG. 1, the software update system 1 includes an update management device 2 and a plurality of slave ECUs 3. The update management device 2 includes a master ECU 21 and a gateway ECU 22. The master ECU 21 is an OTA (Over The Air) ECU, for example, and is an ECU (an electronic control unit including a CPU or the like) that receives update software transmitted wirelessly from the outside of the vehicle. An antenna (for example, a film antenna) B that receives update software transmitted from an external device A such as a server is installed in the vehicle, and the master ECU 21 receives information from the antenna B. It can be said that the master ECU 21 has a receiving unit. The external device A such as a server is installed in the OTA center, for example. The master ECU 21 determines whether the update software corresponds to the software of the slave ECU 3 of the host vehicle. When the received update software corresponds to the slave ECU 3 of the host vehicle, the master ECU 21 transmits the update software to the gateway ECU 22.

  The gateway ECU 22 is an ECU that is communicably connected to the master ECU 21. A plurality of slave ECUs 3 are communicably connected to the gateway ECU 22. The gateway ECU 22 includes a nonvolatile memory 221 that stores update software, and a notification unit 222. The nonvolatile memory 221 is a ROM. As will be described later, the nonvolatile memory 221 (or other memory) includes a common data frame common to all the slave ECUs 3 connected to the gateway ECU 22 and a unique data frame unique to each slave ECU 3. Stored as a data frame.

  The notification unit 222 is configured to transmit an update notification signal to the slave ECU 3 to be updated when the master ECU 21 receives the update software, for example, when a user (driver or the like) accepts the update. The slave ECU 3 that has received the update notification signal recognizes that its own software is to be updated. Details of the notification unit 222 will be described later.

  The plurality of slave ECUs 3 are ECUs that are communicably connected to the gateway ECU 22 and control different in-vehicle devices. For example, as shown in FIG. 1, the first slave ECU 3 is an ECU that controls an engine (ENG), the second slave ECU 3 is an ECU that controls a transmission (T / M), and a third slave The ECU 3 is an ECU that controls a brake device (ESC). As shown in FIG. 2, each slave ECU 3 of the first embodiment includes an MCU (microcomputer unit) 3a and an integrated circuit (ASIC) 3b including a ROM 3c in terms of hardware. The MCU 3a and the integrated circuit 3b are communicably connected via a communication line (here, CAN and serial cable).

  As shown in FIG. 3, each slave ECU 3 includes a storage unit 31, a data frame determination unit 32, a software update unit 33, and a nonvolatile memory 34 as functions or configurations. The storage unit 31 is a memory that stores a predetermined data frame, and is a non-volatile memory in the first embodiment. The storage unit 31 is composed of a ROM 3c. The MCU 3a writes a predetermined data frame to the storage unit 31 (that is, the ROM 3c) via a serial cable at the time of activation. The MCU 3a has its own predetermined data frame set in advance. The predetermined data frame is a data frame indicating that the own ECU has received a wake-up request (start-up request), and is a data array set in advance. One of the predetermined data frames in the first embodiment is the common data frame described above. In addition to the common data frame, a unique data frame uniquely set for each slave ECU 3 is also stored in the storage unit 31 by the MCU 3a as a predetermined data frame. The predetermined data frame may be stored in the storage unit 31 in advance.

  When receiving a signal, the data frame determination unit 32 is configured to determine whether or not the signal matches a predetermined data frame stored in the storage unit 31. The data frame determination unit 32 determines that the received signal matches the predetermined data frame stored in the storage unit 31 when other functions of the slave ECU 3 of the slave ECU 3 are in the sleep state (that is, positive) If the determination is made, the sleep state is canceled for at least some of the other functions. On the other hand, when the data frame determination unit 32 determines that the received signal does not match the predetermined data frame stored in the storage unit 31 (when a negative determination is made), the data frame determination unit 32 activates nothing. It is configured to maintain the sleep state of the function. That is, as a function, the data frame determination unit 32 determines whether or not the received signal matches the predetermined data frame stored in the storage unit 31 when other functions of the slave ECU 3 are in the sleep state. When it is determined that the determination unit 321 and the determination unit 321 match, the release unit 322 that releases and activates at least a part of other functions, and the determination unit 321 do not comply. And a maintenance unit 323 that maintains the sleep state when the determination is made. As will be described later, even when the slave ECU 3 is in the sleep state, only the data frame determination unit 32 is activated, for example, triggered by the start of vehicle communication (signal reception or the like).

  The data frame determination unit 32 of the first embodiment is configured to activate all functions or a part of functions (for example, functions necessary for software update) of its own slave ECU 3 when a positive determination is made. ing. That is, it can be said that the data frame determination unit 32 activates its own slave ECU 3 when making a positive determination and maintains the sleep state of its own slave ECU 3 when making a negative determination. Further, when the slave ECU 3 of the first embodiment is in the sleep state, the data frame determination unit 32 of the first embodiment is in the sleep state until the in-vehicle communication (CAN communication) is started, and is activated when the in-vehicle communication is started. It is configured as follows. The slave ECU 3 can detect the start of in-vehicle communication based on, for example, one or more pulse (corresponding to dominant in CAN communication) input time of communication.

  The software update unit 33 is a part having a software update function, and executes software update in accordance with an instruction from the update management device 2 and / or the MCU 3a. Specifically, the software update unit 33 rewrites (overwrites) the software stored in the nonvolatile memory 34 with the update software transmitted from the update management apparatus 2. The non-volatile memory 34 is a memory in which software is stored, and may be a memory different from the storage unit 31 or a memory (ROM 3c) that is common to the storage unit 31.

  Further, when the software update unit 33 receives an update notification signal from the notification unit 222 in the activated state, the software update unit 33 masks the power down sequence to itself. That is, when receiving the update notification, the software update unit 33 masks (blocks) the power-down sequence (sleep instruction) due to the ignition being turned off. Thereby, the masked slave ECU 3 is maintained in the activated state without entering the sleep state even after the ignition is turned off. With the mask, power supply from the battery Z to the slave ECU 3 to be updated is continued.

  Here, the notification unit 222 of the update management apparatus 2 will be further described. When all the slave ECUs 3 are in the activated state (for example, the ignition is turned on), the notification unit 222 transmits an update notification signal to the slave ECU 3 to be updated without using a predetermined data frame. In this case, since each slave ECU 3 is already activated, each data frame determination unit 32 does not need to make a determination, and its function is substantially stopped. The software update unit 33 of the update target slave ECU 3 that has received the update notification signal masks the power-down sequence as described above. When the ignition is turned off, only the update management device 2 (at least the gateway ECU 22) and the slave ECU 3 to be updated are activated, and the update management device 2 transmits the update software to the slave ECU 3 to be updated. At this time, in the slave ECU 3 that is not to be updated in the sleep state, each data frame determination unit 32 is activated by detecting the start of communication, and determines whether or not the received signal matches a predetermined data frame. As a result, the slave ECU 3 to be updated is maintained while being activated, and the slave ECU 3 that is not to be updated is determined to be nonconforming by the data frame determination unit 32, and waits without being activated (that is, maintains the sleep state).

  On the other hand, when the plurality of slave ECUs 3 are in the sleep state, the notification unit 222 sends an update notification signal including a predetermined data frame (that is, a unique data frame) corresponding only to the update target slave ECU 3 to the update target slave ECU 3. Send. For example, when all the slave ECUs 3 are in the sleep state (for example, in a state where the ignition is turned off), when the notification unit 222 transmits an update notification signal to the update target slave ECU 3, it corresponds to the update target slave ECU 3. The unique data frame to be transmitted is transmitted to the update target slave ECU 3 as the header of the update notification signal or as the update notification signal itself. In this case, the data frame determination unit 32 of each slave ECU 3 is activated by detecting the start of in-vehicle communication, and determines whether or not the received signal is compatible with its own predetermined data frame. As a result, the data frame determination unit 32 of the slave ECU 3 to be updated determines that it is compatible and activates all or some functions, and the data frame determination unit 32 of the slave ECU 3 that is not the update target matches. It judges that it is not, and waits as it is.

  As described above, the slave ECU 3 in the sleep state is activated only when the received signal matches a predetermined data frame (in this case, either a unique data frame or a common data frame) stored in the storage unit 31. I can say that.

  The flow of the update process of the first embodiment will be described with reference to FIG. When the ignition is turned on (S101), the MCU 3a of each slave ECU 3 is activated and writes a predetermined data frame in its own storage unit 31 (S102). And when master ECU21 receives the update software corresponding to the own vehicle, the said update software will be written in the non-volatile memory 221 of gateway ECU22 (S103). Further, the master ECU 21 confirms whether or not the user can update the software (S104). For example, when the user accepts the software update by a button operation or voice operation (S104: Yes), the gateway ECU 22 sends an update notification signal to the slave ECU 3 to be updated and notifies it (S105). The software update unit 33 of the slave ECU 3 notified of the update masks the transition to the power down (sleep state) (S106).

  Thereafter, when the ignition is turned off (S107), the gateway ECU 22 and the slave ECU 3 to be updated are kept activated, and the other slave ECUs 3 shift to the sleep state by the power-down sequence. Then, the gateway ECU 22 transmits the update software to the update target slave ECU 3 (S108). The software update unit 33 of the slave ECU 3 to be updated rewrites the software stored in the nonvolatile memory 34 with the received update software (S109). At this time, in the slave ECU 3 in the sleep state, the data frame determination unit 32 determines the signal received in association with the data transmission of the gateway ECU 22 (S109). The slave ECU 3 that is not the update target determines that the data arrangement of the update software does not match the predetermined data frame, and maintains the sleep state. Then, the software update in the slave ECU 3 to be updated is completed (S110), and the update process ends. After the update is completed, all ECUs shift to the sleep state. When the user does not accept the update (S104: No), it may be set so that the user can confirm the update again when the ignition is turned on next time.

  According to the first embodiment, by causing the data frame determination unit 32 to function in each slave ECU 3, even when the slave ECU 3 that is not the update target receives a signal, other functions are not activated, and the update target is not activated. The software of the slave ECU 3 can be updated. The slave ECU 3 in the sleep state maintains the sleep state without activating other functions unless it receives a signal suitable for its predetermined data frame. Since the function of the data frame determination unit is simple data comparison, it can be executed with extremely small power. That is, according to the first embodiment, unnecessary activation of the ECU can be suppressed with small power consumption, and as a result, increase in power consumption can be suppressed. For example, the power consumption due to activation of the data frame determination unit 32 is on the order of μA, but the power consumption due to activation of the entire slave ECU 3 is on the order of mA.

  Here, the cause of activation of an ECU that is not an update target in the conventional system will be exemplified. For example, in some systems, it is required to self-check the safety of the ECU before the ignition is turned on and respond to user operations immediately. As a method for realizing this, there is a case where a function for detecting the start of in-vehicle communication and waking up is installed. Since the communication line is shared in the system, there is a possibility that a communication pulse during transmission / reception of the update software is also input to an ECU that is not an update target, and is erroneously recognized as an activation instruction and wakes up. When an ECU unnecessary for updating is activated, the power consumption increases. However, according to the first embodiment, as described above, unnecessary activation of the slave ECU 3 is suppressed, and an increase in power consumption is suppressed.

  According to the first embodiment, even when the update notification signal is transmitted when the ignition is on and the software is updated after the ignition is turned off, or when all the slave ECUs 3 are in the sleep state, the update is performed. Even when a notification signal (a signal including a specific data frame) is transmitted, the sleep state of the slave ECU 3 that is not the update target is maintained by each data frame determination unit 32 of the slave ECU 3 in the sleep state. In the configuration of the first embodiment, it is possible to determine whether or not there is a wake-up request to the own ECU after starting the minimum functional blocks on the hardware side. For this reason, an increase in power consumption is further suppressed.

  In addition, according to the first embodiment, the standby current decreases because the data frame determination unit 32 is also in the sleep state until in-vehicle communication is started. That is, since the wake-up is performed in two stages of the determination of the start of in-vehicle communication and the determination of data frame compatibility, the determination logic of the data frame determination unit 32 is also maintained in the sleep state as much as possible, and the power consumption is further reduced.

  In addition, since a common data frame is set as the predetermined data frame, for example, when the update management device 2 transmits a signal including the common data frame to each slave ECU 3, a plurality of slave ECUs 3 (here, gateway ECUs 22). All slave ECUs 3) connected to can be activated at once. The speed of response to requests in the system is maintained.

<Second embodiment>
The software update system according to the second embodiment is different from the first embodiment in terms of operation power supply voltage and / or operation clock. Therefore, a different part is demonstrated. In the description of the second embodiment, reference can be made to the description of the first embodiment and the drawings.

  In the second embodiment, as shown in FIG. 5, after the ignition is turned off (S201), the update target slave ECU 3 requests the update management device 2 to execute software update as a pre-stage of transmission of the update software. Then (S202), the slave ECU 3 or the update management device 2 measures the voltage of the battery Z (hereinafter referred to as “battery voltage”) (S203). Here, whether or not the battery voltage is smaller than the first threshold is determined by the slave ECU 3 or the update management device 2 (S204). When the battery voltage is smaller than the first threshold (S204: Yes), the slave ECU 3 or the update management device 2 can integrate the integrated IC (for example, update management) in which the power supply voltage switching instruction can control the power supply voltage so as to lower the operation power supply voltage. It may be sent to the device 2) (S205).

  After the power supply voltage switching instruction is transmitted, or when the battery voltage is equal to or higher than the first threshold (S204: No), it is determined by the slave ECU 3 or the update management device 2 whether the battery voltage is lower than the second threshold. (S206). The second threshold value is set to a value smaller than the first threshold value. When the battery voltage is smaller than the second threshold (S206: Yes), the slave ECU 3 or the update management device 2 transmits a clock switching instruction to the integrated IC so as to lower the operation clock (decrease the clock frequency). (S207). After the clock switching instruction is transmitted, or when the battery voltage is equal to or higher than the second threshold (S206: No), software update (rewriting) is executed (S208). As a result, the relationship between the battery voltage at the time of software update, the operation power supply voltage, and the operation clock is as shown in FIG. As described above, the update management device 2 or the slave ECU performs at least one of lowering the operating power supply voltage and lowering the operating clock when updating the software.

According to the second embodiment, it is possible to reduce power consumption during software update without sacrificing update processing time as much as possible and without sacrificing communication quality (noise resistance) as much as possible. Specifically, when the operating power supply voltage is lowered, noise resistance deteriorates. Therefore, when the battery voltage is equal to or higher than the first threshold, the battery is operated at a normal voltage. When the battery voltage is smaller than the second threshold value, the operation clock is lowered in order to give priority to the reduction of power consumption. When the battery voltage is equal to or higher than the second threshold, the operation clock is not lowered because it is not desired to sacrifice the update processing time. In the second embodiment, even when an abnormal operation of peripheral components due to a decrease in the operating power supply voltage is detected, the abnormality is ignored when updating software. Further, the degree of battery deterioration can be estimated from the battery voltage, and the operation clock can be lowered according to the degree of deterioration.
In the process of the second embodiment, S204 and S205 or S206 and S207 may be omitted. That is, only the operation clock or the operation power supply voltage may be changed. For example, only S204 may be omitted. In this case, a power supply voltage switching instruction is issued regardless of the battery voltage, and whether or not the operation clock is changed is determined according to the battery voltage. Thereby, the power consumption at the time of update can be reduced without sacrificing the update processing time as much as possible. Specifically, in order to reduce power consumption as much as possible, the operating power supply voltage is always lowered during updating (during rewriting). Further, the difference in processing due to the magnitude relationship between the battery voltage and the second threshold is the same as in the case where S204 is not omitted.

<Others>
The present invention is not limited to the above embodiment. For example, the notification unit 222 may be provided in the master ECU 21. Further, the nonvolatile memory 221, the storage unit 31, and the nonvolatile memory 34 may be flash memories. Moreover, the data frame determination part 32 should just activate the software update part 33 (update function) at least, when it makes a positive determination. In addition, when the notification unit 222 is configured to transmit the update notification signal only when the ignition is on, it is not necessary to individually start the slave ECU 3, and therefore only a common data frame as a predetermined data frame May be stored in the storage unit 31. The update management device 2 may be composed of one ECU. Further, the storage unit 31 may be configured by a volatile memory. However, in this case, electric power for holding the memory of the storage unit 31 is required during sleep.

DESCRIPTION OF SYMBOLS 1 ... Software update system, 2 ... Update management apparatus, 21 ... Master ECU, 22 ... Gateway ECU, 221 ... Non-volatile memory, 222 ... Notification part, 3 ... Slave ECU, 31 ... Memory | storage part, 32 ... Data frame determination part, 33: Software update unit, 34: Non-volatile memory.

Claims (6)

A software update system installed in a vehicle that executes software updates for a plurality of in-vehicle devices,
An update management device for receiving update software transmitted wirelessly from outside the vehicle;
A plurality of ECUs connected to the update management device so as to be communicable and controlling the different in-vehicle devices, and
With
Each of the plurality of ECUs stores a predetermined data frame and data for determining whether or not the signal matches the predetermined data frame stored in the storage unit when a signal is received A frame determination unit,
The data frame determination unit
A determination unit that determines whether or not the signal conforms to the predetermined data frame stored in the storage unit when another function of the ECU is in a sleep state;
If it is determined that the determination unit is suitable, a release unit that releases and activates the sleep state for at least some of the other functions;
When it is determined that the determination unit does not fit, a maintenance unit that maintains the sleep state;
A software update system comprising: The update management device includes a notification unit that transmits an update notification signal to the ECU to be updated when the update software is received,
Each of the plurality of ECUs includes a software update unit having a software update function,
2. The software update system according to claim 1, wherein the software update unit masks a power-down sequence to itself when receiving the update notification signal from the notification unit in an activated state.   The notification unit, when the plurality of ECUs are in the sleep state, transmits the update notification signal including the predetermined data frame corresponding only to the ECU to be updated to the ECU to be updated. The described software update system.   The data frame determination unit is in the sleep state until in-vehicle communication is started when the ECU of the ECU is in the sleep state, and is activated when the in-vehicle communication is started. The software update system according to one item.   The software update according to any one of claims 1 to 4, wherein the update management device or the ECU performs at least one of lowering an operation power supply voltage and lowering an operation clock when updating the software. system.   The software update system according to claim 1, wherein the storage unit stores a common data frame common to the plurality of ECUs as the predetermined data frame.

Images