In-vehicle device, in-vehicle system, control method, and computer program
By implementing a temporary cluster configuration that selectively wakes up only updated ECUs during updates in in-vehicle systems, the method addresses the issue of excessive power consumption associated with ECU updates, enhancing battery efficiency.
Patent Information
- Application Number
- JP2022062434
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Filing Date
- 2022-04-04
- Publication Date
- 2025-05-27
- Estimated Expiration
- 2042-04-04
AI Technical Summary
In in-vehicle systems, updating ECUs can lead to excessive power consumption due to unnecessary wake-ups of non-updated ECUs within a cluster, especially when trying to minimize battery power usage.
The system introduces a temporary cluster configuration where only ECUs intended for update are woken up, while non-updated ECUs remain in sleep mode, by distributing setting information and control messages to manage cluster validity.
This approach effectively reduces power consumption during ECU updates by ensuring only necessary ECUs are active, thereby optimizing battery life, especially in low-power situations like vehicle ignition off.
Smart Images

Figure 0007683526000001 
Figure 0007683526000002 
Figure 0007683526000003
Abstract
Description
Technical Field
[0001] The present disclosure relates to an in-vehicle device, an in-vehicle system, a control method, and a computer program.
Background Art
[0002] An in-vehicle network to which a plurality of ECUs (Electronic Control Units) are connected is known. In recent years, with the increase in the number of ECUs mounted on vehicles, in order to suppress the power consumption of the entire system, a partial network function has been developed in which only some of the ECUs used for control are woken up and the other ECUs are put to sleep. When using the partial network function, a technique for smoothly waking up ECUs by clustering a group of cooperating ECUs is known.
[0003] Non-Patent Document 1 discloses a technique for communicating request and release information of a partial network cluster (PNC) between ECUs using a network management message (NM message).
[0004] Patent Document 1 discloses a technique for forming a PNC between ECUs that communicate data frames with each other. For example, a first PNC is formed between an ECU for an air conditioner and an ECU for a meter indicating the operating status of the air conditioner. Each ECU creates an NM frame including PNC information indicating in which of a plurality of PNCs data frame communication is to be performed, and transmits the NM frame to other ECUs via the in-vehicle network.
[0005] Patent Document 2 discloses a control device belonging to a first cluster and a control device belonging to a second cluster. Each control device transmits a network management frame including a sleep permission bit indicating whether sleep is permitted for each cluster to other control devices. When the sleep permission bit of the first cluster included in the network management frame is "1", the control device belonging to the first cluster stops sleeping and enters an active state.
Prior Art Documents
Patent Documents
[0006]
Patent Document 1
Patent Document 2
Non-Patent Documents
[0007]
Non-Patent Document 1
Summary of the Invention
Problems to be Solved by the Invention
[0008] In an in-vehicle system that controls the wake-up and sleep of ECUs in units of clusters such as PNC, the program of the ECU may be updated by update data distributed in units of clusters. In this case, when update data targeted at a predetermined cluster is distributed, all ECUs belonging to the predetermined cluster wake up.
[0009] However, there may be cases where the predetermined cluster includes an ECU that is not updated by the update data. That is, there may be cases where only some of the ECUs belonging to the predetermined cluster are updated by the update data. In this case, since the non-updated ECUs are also woken up unnecessarily, there is a risk of excessive power consumption in the in-vehicle system when updating the ECUs.
[0010] In particular, ECU updates are often executed in situations where it is desired to further suppress power consumption of the vehicle battery, such as when the vehicle ignition is turned off. Therefore, it is necessary to suppress the power consumption associated with ECU updates.
[0011] In view of such problems, an object of the present disclosure is to provide an in-vehicle device, an in-vehicle system, a control method, and a computer program capable of suppressing power consumption associated with ECU updates.
Means for Solving the Problems
[0012] The in-vehicle device of the present disclosure is an in-vehicle device that distributes update data provided from outside the vehicle to a plurality of ECUs connected via a communication bus. The in-vehicle device includes a control unit. The plurality of ECUs each belong to at least one of a plurality of clusters. In a control message received from the communication bus, when the cluster to which the own ECU belongs is invalid, it enters a sleep mode in which the function is restricted more than in the normal mode to suppress power consumption, and when the cluster to which the own ECU belongs is valid, it enters the normal mode. Prior to distributing first update data, which is the update data targeting a first cluster among the plurality of clusters, the control unit distributes setting information for setting a temporary cluster that includes update ECUs updated by the first update data and does not include non-update ECUs not updated by the first update data among the plurality of ECUs belonging to the first cluster to the plurality of ECUs belonging to the first cluster. When distributing the first update data, the control unit distributes a control message to the plurality of ECUs in which the first cluster is invalidated and the temporary cluster is validated.
[0013] The control method of the present disclosure is a control method for controlling an in-vehicle device that distributes update data provided from outside the vehicle to a plurality of ECUs connected via a communication bus. The plurality of ECUs each belong to at least one of a plurality of clusters. In a control message received from the communication bus, when the cluster to which the own ECU belongs is invalid, it enters a sleep mode in which the function is restricted more than in the normal mode to suppress power consumption, and when the cluster to which the own ECU belongs is valid, it enters the normal mode. The control method includes, prior to distributing first update data, which is the update data targeted at a first cluster among the plurality of clusters, a first step of distributing setting information for setting a temporary cluster that includes the update ECUs updated by the first update data and does not include the non-update ECUs not updated by the first update data, among the plurality of ECUs belonging to the first cluster, to the plurality of ECUs belonging to the first cluster; and a second step of distributing, when distributing the first update data, a control message in which the first cluster is made invalid and the temporary cluster is made valid, to the plurality of ECUs.
[0014] The computer program of the present disclosure is a computer program for controlling an in-vehicle device that distributes update data provided from outside the vehicle to a plurality of ECUs connected via a communication bus. The plurality of ECUs each belong to at least one of a plurality of clusters. In a control message received from the communication bus, when the cluster to which the own ECU belongs is invalid, it enters a sleep mode in which the function is restricted more than in the normal mode to suppress power consumption, and when the cluster to which the own ECU belongs is valid, it enters the normal mode. The computer program causes the computer to, prior to distributing first update data, which is the update data targeted at a first cluster among the plurality of clusters, distribute setting information for setting a temporary cluster that includes an update ECU to be updated by the first update data and does not include a non-update ECU not to be updated by the first update data, among the plurality of ECUs belonging to the first cluster, to the plurality of ECUs belonging to the first cluster in a first step, and in a second step, when distributing the first update data, distribute a control message in which the first cluster is invalidated and the temporary cluster is validated, to the plurality of ECUs.
Advantages of the Invention
[0015] According to the present disclosure, it is possible to suppress power consumption associated with updating the ECU.
Brief Description of the Drawings
[0016]
Figure 1
Figure 2
Figure 3
Figure 4
Figure 5
Figure 6
Figure 7
Figure 8
Figure 9
Figure 10
Figure 11
Figure 12
Figure 13
Figure 14
Figure 15
Embodiments for Carrying Out the Invention
[0017] [Description of Embodiments of the Present Disclosure] The embodiments of the present disclosure mainly include the following configurations.
[0018] (1) The in-vehicle device of the present disclosure is an in-vehicle device that distributes update data provided from outside the vehicle to a plurality of ECUs connected via a communication bus. The in-vehicle device includes a control unit. The plurality of ECUs each belong to at least one of a plurality of clusters. In a control message received from the communication bus, when the cluster to which the own ECU belongs is invalid, it enters a sleep mode in which the functions are restricted more than in the normal mode to suppress power consumption, and when the cluster to which the own ECU belongs is valid, it enters the normal mode. Prior to distributing first update data, which is the update data targeting a first cluster among the plurality of clusters, the control unit distributes setting information for setting a temporary cluster that includes update ECUs updated by the first update data and does not include non-update ECUs not updated by the first update data among the plurality of ECUs belonging to the first cluster to the plurality of ECUs belonging to the first cluster. When distributing the first update data, the control unit distributes a control message in which the first cluster is set to invalid and the temporary cluster is set to valid to the plurality of ECUs.
[0019] By distributing a control message in which the first cluster is set to invalid and the temporary cluster is set to valid to the plurality of ECUs, only the update ECUs can be woken up and the non-update ECUs can be maintained in the sleep mode, so that the power consumption for ECU update can be suppressed.
[0020] (2) The in-vehicle device according to (1) may further include a storage unit that stores cluster information associating the plurality of ECUs with the clusters to which the plurality of ECUs each belong. The control unit may determine whether each of the plurality of ECUs belonging to the first cluster is an update ECU or a non-update ECU based on the update information provided from outside the vehicle prior to the first update data or prior to the provision of the first update data and the cluster information.
[0021] As a result, in the control unit, it is possible to determine whether each of the plurality of ECUs belonging to the first cluster is an updated ECU or a non-updated ECU.
[0022] (3) In the in-vehicle device according to (1) or (2) above, after the control unit distributes the first update data, the control unit may distribute, to the plurality of ECUs belonging to the first cluster, discard information for discarding the setting of the temporary cluster.
[0023] By configuring in this way, it is possible to dynamically set a temporary cluster within a limited number of clusters.
[0024] (4) In the in-vehicle device according to any one of (1) to (3) above, when a new ECU belonging to the first cluster is added to the communication bus prior to the distribution of the first update data, the control unit may acquire, before the new ECU is added, additional information which is information about the new ECU, and may distribute the additional information to the plurality of ECUs belonging to the first cluster prior to the distribution of the first update data.
[0025] By configuring in this way, prior to distributing the first update data, information about a new ECU can be transmitted in advance to the ECUs belonging to the first cluster. As a result, non-updated ECUs that remain in the sleep mode when the first update data is distributed can detect in advance that a new ECU will be added. Thereby, the reliability of the in-vehicle system can be improved.
[0026] (5) In the in-vehicle device according to any one of (1) to (4) above, in a state where the control unit has made the plurality of ECUs belonging to the first cluster into the normal mode by the control message that enables the first cluster, the control unit may distribute the setting information to the plurality of ECUs belonging to the first cluster.
[0027] Even when the destination ECU is in the sleep mode, the control unit can more reliably deliver the setting information to the ECU by temporarily waking up the destination ECU and then delivering the setting information.
[0028] (6) In any of the in-vehicle devices according to (1) to (5) above, after the updated ECU is updated with the first update data, when the first non-updated ECU, which is the non-updated ECU connected to the same communication bus as the updated ECU, enters the normal mode, the control unit may notify the first non-updated ECU of the update content of the updated ECU based on the first update data.
[0029] This can prevent the update content of the updated ECU from causing problems in the operation of the first non-updated ECU.
[0030] (7) In any of the in-vehicle devices according to (1) to (6) above, a plurality of the ECUs may include competing ECUs that switch to the normal mode by a first control message before the setting of the temporary cluster, do not switch to the normal mode by the first control message after the setting of the temporary cluster, and switch to the normal mode by a second control message different from the first control message. When the control unit receives the first control message addressed to the competing ECU after the setting of the temporary cluster, the control unit may transmit the second control message to the competing ECU. While the competing ECU is in the normal mode by the second control message, the control unit may transmit activation information for setting the first control message to switch the competing ECU to the normal mode to the competing ECU. After transmitting the activation information, the control unit may transmit the first control message to the competing ECU.
[0031] By temporarily changing the cluster setting of a competing ECU that has stopped waking up due to the competition of temporary clusters, it is possible to execute a predetermined control in the competing ECU. As a result, even when the number of clusters is limited and a temporary cluster is set in a cluster that is already in use, it is possible to suppress the occurrence of problems in the in-vehicle system.
[0032] (8) In the in-vehicle device according to (7) above, after transmitting the activation information and the first control message to the competing ECU, the control unit transmits invalidation information to the competing ECU for setting so that the first control message does not switch the competing ECU to the normal mode.
[0033] In this way, by restoring the cluster setting of the competing ECU, it is possible to keep the competing ECU in the sleep mode when updating the update ECU with the first update data, so that the power consumption in the in-vehicle system during the update can be suppressed.
[0034] (9) In the in-vehicle device according to (7) or (8) above, the control message includes an immediacy message in which the allowable time from when the control unit receives the control message until the control based on the control message is executed in the competing ECU is less than a first threshold value, and a non-immediacy message in which the allowable time is greater than or equal to the first threshold value, and the first control message is the non-immediacy message.
[0035] By configuring in this way, it is possible to suppress the occurrence of a delay in the control with a short allowable time.
[0036] (10) An in-vehicle system including the in-vehicle device according to any one of (1) to (9) above and a plurality of the ECUs connected to the in-vehicle device via the communication bus.
[0037] (11) The control method of the present disclosure is a control method for controlling an in-vehicle device that distributes update data provided from outside the vehicle to a plurality of ECUs connected via a communication bus. The plurality of ECUs each belong to at least one of a plurality of clusters. In a control message received from the communication bus, when the cluster to which the own ECU belongs is invalid, it enters a sleep mode in which the function is restricted more than in the normal mode to suppress power consumption, and when the cluster to which the own ECU belongs is valid, it enters the normal mode. The control method includes, prior to distributing first update data, which is the update data targeted at a first cluster among the plurality of clusters, first step of distributing setting information for setting a temporary cluster that includes update ECUs updated by the first update data and does not include non-update ECUs not updated by the first update data, among the plurality of ECUs belonging to the first cluster, to the plurality of ECUs belonging to the first cluster; and a second step of distributing, when distributing the first update data, a control message in which the first cluster is invalidated and the temporary cluster is validated, to the plurality of ECUs.
[0038] By distributing a control message in which the first cluster is invalidated and the temporary cluster is validated to a plurality of ECUs, only the update ECUs can be woken up and the non-update ECUs can be maintained in the sleep mode, so that the power consumption required for updating the ECUs can be suppressed.
[0039] (12) The computer program of the present disclosure is a computer program for controlling an in-vehicle device that distributes update data provided from outside a vehicle to a plurality of ECUs connected via a communication bus. The plurality of ECUs each belong to at least one of a plurality of clusters. In a control message received from the communication bus, when the cluster to which the own ECU belongs is invalid, it enters a sleep mode in which the functions are restricted more than in the normal mode to suppress power consumption, and when the cluster to which the own ECU belongs is valid, it enters the normal mode. The computer program causes a computer to, prior to distributing first update data, which is the update data targeted for a first cluster among the plurality of clusters, distribute setting information for setting a temporary cluster to a plurality of ECUs belonging to the first cluster, where the temporary cluster includes the update ECU updated by the first update data and does not include non-update ECUs not updated by the first update data. The computer program further causes the computer to execute a second step of distributing, to the plurality of ECUs, a control message in which the first cluster is invalidated and the temporary cluster is validated when distributing the first update data.
[0040] By distributing a control message in which the first cluster is invalidated and the temporary cluster is validated to a plurality of ECUs, only the update ECU can be woken up and the non-update ECUs can be maintained in the sleep mode, so that the power consumption required for updating the ECUs can be suppressed.
[0041] [1. Details of Embodiments of the Present Disclosure] Hereinafter, details of embodiments of the present disclosure will be described with reference to the drawings.
[0042] [1.1 Configuration of In-Vehicle System] FIG. 1 is a diagram showing a configuration example of an in-vehicle system 1 according to an embodiment. The in-vehicle system 1 is a system mounted on a vehicle V1 such as an automobile. The in-vehicle system 1 includes an in-vehicle device 10, a plurality of ECUs 20, a communication bus 30, communication lines 41 and 42, and a communication device 50.
[0043] The in-vehicle device 10 functions, for example, as an integrated ECU (Electronic Control Unit) that manages a plurality of ECUs 20. For example, the in-vehicle device 10 functions as a master ECU, and each of the plurality of ECUs 20 functions as a slave ECU. The in-vehicle device 10 distributes update data provided from outside the vehicle V1 (specifically, an external device 61, a diagnostic device 62, or a recording medium 17) to the plurality of ECUs 20.
[0044] The in-vehicle device 10 may function as a GW-ECU (Gateway-ECU) that relays data transmitted and received between the plurality of ECUs 20. For example, in a network environment where a plurality of different LANs (Local Area Networks) exist in the vehicle V1, the in-vehicle device 10 may relay data transmitted and received by the plurality of ECUs 20 existing in each LAN, and specifically, it may be a central gateway (CGW). The internal configuration of the in-vehicle device 10 will be described later.
[0045] The communication device 50 is a communication interface that performs wireless communication with an external device 61 via a network N1 such as the Internet. Specifically, the communication device 50 is a TCU (Telematics Communication Unit). The communication device 50 transmits data output from the in-vehicle device 10 via the communication line 41 to the external device 61 via the network N1. Also, the communication device 50 inputs data (update data, update information Y1, etc.) transmitted from the external device 61 via the network N1 to the in-vehicle device 10 via the communication line 41.
[0046] The external device 61 is a device installed outside the vehicle V1. The external device 61 is, for example, a server including a control unit, a storage unit, and a communication unit. The storage unit of the external device 61 stores, for example, a program or data for controlling each part of the in-vehicle system 1 (for example, the in-vehicle device 10 or the ECU 20). For example, the manufacturer of the ECU 20 modifies the program or data as needed and stores the modified program or data in the storage unit of the external device 61 at any time. The communication unit of the external device 61 transmits the modified program or data to the in-vehicle device 10 as update data. For this reason, the external device 61 is also referred to as an OTA (Over The Air) server.
[0047] Prior to transmitting the update data to the in-vehicle device 10, the external device 61 may transmit update information Y1 including information (such as the address of the ECU) for identifying the ECU to be updated by the update data to the in-vehicle device 10.
[0048] The update data may be a program (application program) for updating the software of the ECU 20, or may be a program (firmware program) for updating the firmware of the ECU 20. Further, the update data may be data for updating the parameter information stored in the ECU 20. The parameter information is data used for the software realized in the ECU 20, and specifically, is map information, control parameters, and the like.
[0049] The diagnostic device 62 (also referred to as a "diagnostic tool") is a device used by a vehicle maintenance provider (for example, a dealer) responsible for the maintenance of the vehicle V1. The diagnostic device 62 is, for example, a general-purpose information terminal such as a personal computer, a tablet terminal, or a smartphone in which an application for diagnosing the state of each part (such as the ECU 20) of the in-vehicle system 1 is installed. Further, the diagnostic device 62 may be a dedicated terminal in which the application is installed.
[0050] The diagnostic device 62 has a control unit, a storage unit, and a communication unit. When performing maintenance work or the like on the in-vehicle system 1 using the diagnostic device 62, the communication unit of the diagnostic device 62 is connected to the in-vehicle device 10 via the communication line 42. The communication unit of the diagnostic device 62 communicates with the external device 61 via the network N1 according to a wireless communication standard such as Wi-Fi, for example. The diagnostic device 62 downloads update data from the external device 61 via the network N1. The diagnostic device 62 transmits the update data to the in-vehicle device 10 via the communication line 42.
[0051] The communication bus 30 extends from the in-vehicle device 10. A plurality of ECUs 20 are each bus-connected to the communication bus 30. In the example of FIG. 1, two communication buses 30 extend from the in-vehicle device 10, but the number of communication buses 30 is not particularly limited. When distinguishing the two communication buses 30, they are respectively referred to as communication buses 31 and 32. The communication bus 30 complies with a communication protocol such as CAN (Controller Area Network), CAN-FD (CAN with Flexible Data Rate), Ethernet (registered trademark), LIN (Local Interconnect Network), CXPI (Clock Extension Peripheral Interface), or FlexRay (registered trademark).
[0052] The in-vehicle device 10 is connected to a plurality of (five in the example of FIG. 1) ECUs 20 via the communication bus 30. In the example of FIG. 1, the in-vehicle device 10 is connected to three ECUs 20 via the communication bus 31 and two ECUs 20 via the communication bus 32. When distinguishing the plurality of ECUs 20, the ECUs 20 connected to the communication bus 31 are sequentially referred to as ECUs 21, 22, and 23 from top to bottom, and the ECUs 20 connected to the communication bus 32 are sequentially referred to as ECUs 24 and 25 from top to bottom.
[0053] The number of ECUs 20 included in the in-vehicle system 1 is not particularly limited as long as it is two or more. The ECU 20 is, for example, a device (operation system ECU) that controls each part of the vehicle V1 (e.g., braking device, door, battery, air conditioner, etc.). The function of the ECU 20 is not particularly limited, and the ECU 20 may be a device (cognition system ECU) that communicates with sensors and monitors the states of each part of the vehicle V1. The plurality of ECUs 20 may each have different functions or may each have the same function.
[0054] The plurality of ECUs 20 support the partial network function and respectively belong to at least one of a plurality of clusters. Here, a cluster is a data set that defines a group of ECUs that synchronously execute at least one of wake-up and sleep among the plurality of ECUs 20, and is, for example, a partial network cluster (PNC). Specific examples of the clusters set in the in-vehicle system 1 will be described later.
[0055] [1.2 Internal Configuration of In-Vehicle Device 10] FIG. 2 is a diagram showing an example of the internal configuration of the in-vehicle device 10. The in-vehicle device 10 includes a microcontroller unit 11 (hereinafter referred to as "microcomputer 11") including a control unit 12 and a storage unit 13, a reading unit 14, and a plurality of transceivers 15a to 15d. These units are electrically connected by a bus 16.
[0056] The control unit 12 includes a circuit configuration (Circuitry) such as a processor. Specifically, the control unit 12 includes one or a plurality of CPUs (Central Processing Unit). The processor included in the control unit 12 may be a GPU (Graphics Processing Unit). In this case, the control unit 12 reads out the computer program stored in the storage unit 13 and executes various operations and controls.
[0057] The control unit 12 may include a processor with a predetermined program written therein in advance. For example, the control unit 12 may be an integrated circuit such as a CPLD (Complex Programmable Logic Device), an FPGA (Field-Programmable Gate Array), or an ASIC (Application Specific Integrated Circuit). In this case, the control unit 12 executes various operations and controls based on the pre-written program.
[0058] The storage unit 13 has a volatile memory and a non-volatile memory, and stores various data. The volatile memory includes, for example, a RAM (Random Access Memory). The non-volatile memory includes, for example, a flash memory, an HDD (Hard Disk Drive), an SSD (Solid State Drive), or a ROM (Read Only Memory). A part of the non-volatile memory may be provided outside the microcomputer 11.
[0059] The storage unit 13 stores, for example, a computer program, cluster information described later, and various parameters in the non-volatile memory. The storage unit 13 may store a computer program downloaded from the external device 61 via the network N1 and the communication device 50.
[0060] The reading unit 14 reads information from a computer-readable recording medium 17. The recording medium 17 is, for example, an optical disk such as a CD or a DVD, an SD memory card, or a USB flash memory. The reading unit 14 is, for example, an optical drive, a memory card slot, or a USB terminal. A computer program, update data, and various parameters are recorded on the recording medium 17. By causing the recording medium 17 to be read by the reading unit 14, the computer program, update data, and various parameters are stored in the non-volatile memory of the storage unit 13.
[0061] Transceivers 15a to 15d receive the signals flowing through communication bus 30 or communication lines 41 and 42 via ports (not shown), respectively, and convert them into signals readable by microcomputer 11. Transceiver 15a is connected to communication bus 31, transceiver 15b is connected to communication bus 32, transceiver 15c is connected to communication line 41, and transceiver 15d is connected to communication line 42.
[0062] [1.3 Internal Configuration of ECU20] FIG. 3 is a diagram showing an example of the internal configuration of ECU21. Since the internal configurations of the other ECUs 20 are the same as that of ECU21, the description thereof is omitted.
[0063] ECU21 includes a microcontroller unit 71 (hereinafter referred to as "microcomputer 71") including a control unit 73 and a storage unit 74, and a transceiver 72 including a register 75. Transceiver 72 is electrically connected to microcomputer 71. ECU21 further includes a power supply circuit (not shown) that converts the power supplied from a power supply (not shown) and supplies the converted power to these respective units 71 and 72.
[0064] Similar to control unit 12, control unit 73 includes a circuit configuration such as a processor. For example, control unit 73 reads out the computer program stored in storage unit 74 and executes various operations and controls. Also, similar to control unit 12, control unit 73 may include a processor in which a predetermined program is written in advance. In this case, control unit 73 executes various operations and controls based on the program written in advance.
[0065] Similar to storage unit 13, storage unit 74 has a volatile memory and a non-volatile memory, and stores various data. Storage unit 74 stores, for example, a computer program and various parameters in the non-volatile memory.
[0066] The transceiver 72 is a transceiver that supports a partial network function and includes an integrated circuit (IC). The transceiver 72 is, for example, a CAN transceiver or an SBC (System Basis Chip). The transceiver 72 is connected to the communication bus 31 and receives various control messages from the communication bus 31.
[0067] The transceiver 72 includes a transmission circuit, a reception circuit, and a detection circuit (each not shown). The transmission circuit and the reception circuit communicate in accordance with the same communication protocol as the communication bus 31. The transmission circuit converts the data of the digital signal output by the microcomputer 71 into a three-level analog signal and sends it out to the communication bus 31. The data converted into an analog signal is broadcast on the communication bus 31. The reception circuit converts the analog signal input from the communication bus 31 into a digital signal that can be read by the microcomputer 71 and outputs the digital signal to the microcomputer 71.
[0068] The detection circuit has a function of determining whether the control message received from the communication bus 31 is a control message destined for the ECU 21. And when the detection circuit determines that the received control message is a control message destined for the ECU 21, it switches the ECU 21 from the sleep mode to the normal mode.
[0069] Specifically, when the transceiver 72 receives a control message that conforms to the cluster information T2 (described later) recorded in the register 75, it switches the ECU 21 from the sleep mode to the normal mode (that is, wakes up the ECU 21).
[0070] [1.4 Partial Networking of the In-vehicle System 1] In order to suppress the power consumption of the in-vehicle system 1 as a whole, the in-vehicle system 1 uses a network management function to wake up only some of the ECUs 20 used for control and keep the other ECUs 20 in a sleep state at all times. The ECU 20 can be switched between a normal mode and a sleep mode, and these mode switches are basically executed based on control messages broadcast on the communication bus 30. The control messages are also referred to as network management frames (NM frames).
[0071] The normal mode is a mode in which the ECU 20 is awake and the functions of the ECU 20 necessary for various controls are available. For example, in the normal mode, the clock circuit of the processor included in the ECU 20 is operating at a preset number of clocks.
[0072] The sleep mode is a mode that restricts the functions of the ECU 20 compared to the normal mode to suppress power consumption. For example, in the sleep mode, the power supply to the clock circuit of the processor included in the ECU 20 is stopped, and the operations of the clock circuit and the processor are stopped. Note that the sleep mode may be a state in which power is supplied to the clock circuit of the processor included in the ECU 20, but the power consumption is suppressed by operating at a number of clocks less than that in the normal mode.
[0073] For example, the ECU 20 automatically switches from the normal mode to the sleep mode when it is not used continuously for a predetermined time or when it executes a predetermined control. Even while the ECU 20 is in the sleep mode, the power supply from the power circuit of the ECU 20 to the detection circuit of the transceiver 72 is continued. Thereby, in the sleep mode, the transceiver 72 can detect the control message.
[0074] A control message for switching the ECU 20 from the sleep mode to the normal mode is generated, for example, in the in-vehicle device 10 or another ECU 20 and broadcast on the communication bus 30. The control message includes an information pattern indicating a cluster to be woken up, and each ECU 20 is woken up for each cluster to which each ECU 20 belongs based on the control message.
[0075] Here, the cluster will be described. A plurality of ECUs 20 each belong to at least one cluster. The storage unit 13 of the in-vehicle device 10 stores cluster information T1 associating the plurality of ECUs 20 with the clusters to which the plurality of ECUs 20 belong.
[0076] FIG. 4 is a table showing an example of the cluster information T1. In the cluster information T1, it shows which ECU 20 belongs to each of the eight clusters C1 to C8. Note that the number of clusters in FIG. 4 is an example, and nine or more clusters may be prepared. In the table, "1" indicates that the ECU 20 belongs to the cluster of that row, and "0" indicates that the ECU 20 does not belong to the cluster of that row.
[0077] For example, as shown in FIG. 1, ECUs 21, 22, 24, and 25 belong to the cluster C1. Also, ECUs 22 and 23 belong to the cluster C2. ECUs 21 to 25 belong to the cluster C3. Thus, one ECU 20 may belong to a plurality of clusters. And, ECUs 21 to 25 do not belong to the cluster C8, which is a so-called "empty" cluster. In the following description, "waking up the ECUs 21, 22, 24, and 25 belonging to the cluster C1" is also simply expressed as "waking up the cluster C1". The same expression is used for the other clusters C2 to C8.
[0078] Next, a control message for waking up the ECU 20 for each cluster will be described. The control message includes a data field F1 that indicates the cluster to be woken up among the plurality of clusters C1 to C8.
[0079] FIG. 5 is a diagram illustrating the association between each bit of the data field F1 and the clusters C1 to C8. The data field F1 is composed of, for example, 8 bits, and the clusters C1 to C8 are assigned to each bit. For example, cluster C1 is assigned to the first bit (Bit0).
[0080] FIG. 6 is a diagram showing an example of the data field F1 included in the control message. The ECU 20 that has received the control message wakes up when it belongs to the cluster corresponding to the bit that is "1" in the data field F1. For example, in the data field F1 of FIG. 6, Bit0 is "1" and Bits 1 to 7 are "0". Therefore, as shown in FIG. 5, among the ECUs 20 that have received the control message including this data field F1, only the ECUs 21, 22, 24, and 25 belonging to cluster C1 wake up.
[0081] Hereinafter, in the data field F1 of the control message, setting a bit to "1" will be appropriately expressed as "enabling" the cluster corresponding to that bit, and setting a bit to "0" will be appropriately expressed as "disabling" the cluster corresponding to that bit.
[0082] Each ECU 20 stores the cluster information T2 in the register 75. The cluster information T2 is information indicating the cluster to which the ECU 20 itself belongs. For example, in the case of ECU 21, the information in the first column (the column indicating the cluster to which ECU 21 belongs) of the cluster information T1 shown in FIG. 4 is stored in the register 75 as the cluster information T2. Also, in the case of ECU 22, the information in the second column of the cluster information T1 is stored in the register 75 as the cluster information T3.
[0083] When the transceiver 72 of the ECU 20 receives a control message including the data field F1 via the communication bus 30, it determines whether the cluster information T2 stored in its own register 75 matches the data field F1. Specifically, the transceiver 72 calculates the product of each bit of the cluster information T2 and the corresponding bit of the data field F1 one by one. If there is a bit that becomes "1" after the calculation, it is determined that the cluster information T2 and the data field F1 "match", and the ECU 20 is woken up.
[0084] In the examples of FIGS. 4 to 6, the cluster information T2 has an 8-bit pattern of "101···0", and the data field F1 has an 8-bit pattern of "100···0". According to FIG. 5, the nth bit of the cluster information T2 corresponds to the nth bit of the data field F1. Since the product of the first bit of the cluster information T2 and the first bit of the data field F1 becomes "1", the ECU 21 wakes up.
[0085] [1.5 Problems to be Solved by the Present Embodiment] In the vehicle-mounted system 1, update data for updating the program of the ECU 20 is provided to the in-vehicle device 10 from outside the vehicle V1, such as an external device 61, a diagnostic device 62, or a recording medium 17. In the vehicle-mounted system 1, in order to control the wake-up and sleep of a plurality of ECUs 20 in units of clusters, the update data is also provided to the in-vehicle device 10 in units of clusters.
[0086] Conventionally, the in-vehicle device 10 has executed the update of the ECU 20 in units of clusters by directly distributing the update data in units of clusters provided from outside the vehicle V1 to a plurality of ECUs 20. For example, when the in-vehicle device 10 receives update data targeting the cluster C1 from the outside, it distributes the update data together with the control message including the data field F1 shown in FIG. 6, thereby waking up all of the ECUs 21, 22, 24, and 25 belonging to the cluster C1.
[0087] However, there may be cases where the cluster C1 includes an ECU20 that is not updated by the update data. In the example of FIG. 1, the ECUs 21, 24, 25 shown with hatching are the ECUs (updated ECUs 21, 24, 25) to be updated by the update data, and the ECU 22 without hatching is an ECU (non-updated ECU 22) that is not the target of the update data. In this case, when the cluster C1 is woken up, the non-updated ECU 22 is also woken up unnecessarily, so there is a possibility of extra power consumption in the in-vehicle system 1.
[0088] In particular, the update of the ECU20 is often executed in a situation where it is desired to further suppress the power consumption of the battery of the vehicle V1, such as when the ignition of the vehicle V1 is turned off. Therefore, it is necessary to suppress the power consumption required for the update of the ECU20.
[0089] Therefore, in the present embodiment, prior to the distribution of update data (hereinafter referred to as first update data D1) targeting the cluster C1, the in-vehicle device 10 distributes setting information Y2 for setting a temporary cluster to which the updated ECUs 21, 24, 25 to be updated by the first update data D1 belong and to which the non-updated ECU 22 not updated by the first update data D1 does not belong, to a plurality of ECUs 21, 22, 24, 25 belonging to the cluster C1.
[0090] Then, after setting the temporary cluster in each of the ECUs 21, 22, 24, 25, when distributing the first update data D1, the in-vehicle device 10 distributes a control message M1 that invalidates the cluster C1 and validates the temporary cluster to the plurality of ECUs 20. As a result, only the updated ECUs 21, 24, 25 can be woken up for update while the non-updated ECU 22 is in a sleep state, so that the power consumption required for the update of the ECU20 can be suppressed.
[0091] Hereinafter, taking the case of updating the ECU20 by the first update data D1 as an example, the specific control content in the in-vehicle system 1 will be described.
[0092] [1.6 Control Method] FIG. 7 is a flowchart showing an example of a control method executed by the in-vehicle system 1. The control executed by the in-vehicle device 10 is shown on the left side of FIG. 7, the control executed by the ECU 21 (updated ECU) is shown in the center of FIG. 7, and the control executed by the ECU 22 (non-updated ECU) is shown on the right side of FIG. 7. Similarly, in the flowcharts after FIG. 8, the controls executed by the in-vehicle device 10, the ECU 21, and the ECU 22 are shown.
[0093] The control executed by the in-vehicle device 10 is executed by the microcomputer 11 or the transceivers 15a to 15d. When the microcomputer 11 executes the control, the control unit 12 reads a computer program from the storage unit 13 (or according to a program pre-written in the control unit 12) and executes various operations and processes.
[0094] The control executed by the ECU 21 is executed by the microcomputer 71 or the transceiver 72. When the microcomputer 71 executes the control, the control unit 73 reads a computer program from the storage unit 74 (or according to a program pre-written in the control unit 73) and executes various operations and processes.
[0095] As shown in FIG. 7, the in-vehicle system 1 executes a temporary cluster forming step (step S100) of forming a temporary cluster including only the updated ECUs 21, 24, and 25 updated by the first update data D1, an update step (step S200) of updating the ECU 20 belonging to the temporary cluster, and a temporary cluster discarding step (step S300) of discarding the setting of the temporary cluster. Note that the temporary cluster discarding step (step S300) may be omitted.
[0096] The temporary cluster forming step S100 is executed, for example, when the ignition switch of the vehicle V1 is on. And the update step S200 is executed when the ignition switch of the vehicle V1 is off. That is, the update data is provided to the in-vehicle device 10 by OTA or the like while the vehicle V1 is running. And during parking of the vehicle V1, the update of the ECU 20 by the update data is executed.
[0097] Note that the temporary cluster formation step S100 may be executed while the ignition switch of the vehicle V1 is off. Also, the state of the vehicle V1 when executing the temporary cluster destruction step S300 is not particularly limited.
[0098] [1.6.1 Temporary Cluster Formation Step] FIG. 8 is a flowchart showing details of the temporary cluster formation step S100 in FIG. 7. First, the in-vehicle device 10 acquires update information Y1 from outside the vehicle V1 (step S111). The update information Y1 includes, for example, information for identifying the cluster targeted by the first update data D1 (e.g., the cluster number of cluster C1) and information for identifying the update ECU to be updated by the first update data D1 (e.g., the addresses of update ECUs 21, 24, 25).
[0099] The in-vehicle device 10 receives, for example, the first update data D1 distributed from the external device 61 via the network and the communication device 50. Then, the in-vehicle device 10 acquires the update information Y1 based on the received first update data D1 (e.g., by analyzing the data content of the first update data D1). Note that the update information Y1 itself may be provided to the in-vehicle device 10 prior to the provision of the first update data D1 from outside the vehicle V1.
[0100] Next, based on the update information Y1 and the cluster information T1, the in-vehicle device 10 determines whether each of the ECUs 21, 22, 24, 25 belonging to the cluster C1 is an update ECU to be updated by the first update data D1 or a non-update ECU not to be updated by the first update data D1 (step S112).
[0101] For example, in-vehicle device 10 identifies cluster C1 to be updated from among a plurality of clusters C1 to C8 based on update information Y1. Then, based on cluster information T1, it identifies ECUs 21, 22, 24, 25 belonging to cluster C1 from among a plurality of ECUs 20. Finally, in-vehicle device 10 extracts update ECUs 21, 24, 25 to be updated by first update data D1 from among ECUs 21, 22, 24, 25 based on update information Y1. And it determines the remaining ECU 22 that was not extracted as a non-updated ECU.
[0102] Subsequently, in-vehicle device 10 generates a temporary cluster to which update ECUs 21, 24, 25 belong and to which non-updated ECU 22 does not belong (step S113). Specifically, control unit 12 generates cluster information T1a including the temporary cluster and stores the cluster information T1a in storage unit 13.
[0103] FIG. 9 is a table showing an example of cluster information T1a including a temporary cluster. As shown in FIG. 9, control unit 12 uses cluster C8 as the temporary cluster. Specifically, in cluster C8, update ECUs 21, 24, 25 are set to "1", and other ECUs 20 including non-updated ECU 22 are set to "0". Since cluster C8 is an empty cluster to which no ECU 20 belongs before the setting of the temporary cluster, by using such a cluster C8 as the temporary cluster, it is possible to suppress the influence on existing clusters.
[0104] Subsequently, control unit 12 distributes setting information Y2 for setting a temporary cluster to ECUs 21, 22, 24, 25 belonging to cluster C1 (steps S114, S115). For example, control unit 12 transmits cluster information T2a to ECU 21 (step S114) and transmits cluster information T3a to ECU 22 (step S115). Cluster information T2a has an 8-bit pattern of "101···1", and cluster information T3a has an 8-bit pattern of "111···0".
[0105] When the destination ECU20 of the setting information Y2 is in the sleep mode, the control unit 12 temporarily wakes up the destination ECU20 and then distributes the setting information Y2. Specifically, when the ECUs 21, 22, 24, 25 belonging to the cluster C1 are in the sleep mode, the control unit 12 distributes a control message (the control message shown in FIG. 6) including the data field F1 that enables the cluster C1 to a plurality of ECUs 20, thereby setting the ECUs 21, 22, 24, 25 belonging to the cluster C1 to the normal mode, and in this state, distributes the setting information Y2 to each of the ECUs 21, 22, 24, 25.
[0106] When the ECU21 receives the cluster information T2a as the setting information Y2, it rewrites the cluster information T2 (101···0) stored in the register 75 to the cluster information T2a (changing the "0" in the 8th bit to "1"), thereby executing a new cluster setting including a temporary cluster (step S121). When the rewriting of the register 75 is completed in the ECU21, the ECU21 transmits a completion notification to the in-vehicle device 10 (step S122).
[0107] When the ECU22 receives the cluster information T3a as the setting information Y2, it rewrites the cluster information T3 stored in the register 75 to the cluster information T3a, thereby executing a new cluster setting including a temporary cluster (step S131). When the rewriting of the register 75 is completed in the ECU22, the ECU22 transmits a completion notification to the in-vehicle device 10 (step S132).
[0108] Note that in the ECU22, there is no change in the cluster setting before and after the setting of the temporary cluster, and the cluster information T3 and the cluster information T3a are the same. In this case, the in-vehicle system 1 may omit the execution of steps S115, S131, and S132.
[0109] When the control unit 12 receives a completion notification from the ECUs 21, 22, 24, 25 belonging to the cluster C1 and other sleep conditions are also satisfied, it distributes a sleep signal for putting the ECUs 21, 22, 24, 25 to sleep (step S116). When receiving the sleep signal, the ECUs 21, 22, 24, 25 switch from the normal mode to the sleep mode (steps S123, S133). Thus, the temporary cluster formation process S100 ends.
[0110] [1.6.2 Update Process] FIG. 10 is a flowchart showing details of the update process S200 in FIG. 7. When distributing the first update data D1, the control unit 12 distributes a control message M1 for waking up only the updated ECUs 21, 24, 25 (step S211). As shown in FIG. 10, the control unit 12 may distribute the control message M1 prior to the distribution of the first update data D1, or may transmit the first update data D1 and the control message M1 simultaneously. Also, the first update data D1 may be included in the control message M1.
[0111] FIG. 11 is a diagram showing an example of the data field F2 of the control message M1. In the data field F2, the cluster C1 (first bit) targeted by the first update data D1 is invalid, and the temporary cluster (in this example, cluster C8, eighth bit) is valid.
[0112] The control message M1 is broadcast from the in-vehicle device 10 to the communication bus 30 and received by each of the plurality of ECUs 20. The transceiver 72 of each ECU 20 determines whether the control message M1 conforms to the cluster information stored in its own register 75 as described above, and wakes up if it conforms.
[0113] Since the ECU 21 belongs to the temporary cluster in the temporary cluster formation process (that is, since the 8th bit of the cluster information T2a is "1"), it wakes up when receiving the control message M1 (step S221). Similarly, the other updated ECUs 24 and 25 also wake up. On the other hand, since the ECU 22 does not belong to the temporary cluster, it does not wake up even when receiving the control message M1 and remains in the sleep mode.
[0114] Then, the control unit 12 distributes the first update data D1 to the plurality of ECUs 20 (step S212). Note that when the first update data D1 is included in the control message M1 as described above, steps S211 and S212 are executed simultaneously. The first update data D1 is received by the updated ECUs 21, 24, and 25 that have woken up, and the updated ECUs 21, 24, and 25 are updated respectively (step S222). When the update of the ECU 21 is completed, it transmits a completion notification to the in-vehicle device 10 (step S223), and then switches from the normal mode to the sleep mode (step S224).
[0115] Thus, the update process S200 ends. In this way, by distributing the control message M1 that invalidates the cluster C1 and validates the temporary cluster to the plurality of ECUs 20, only the updated ECUs 21, 24, and 25 can be woken up, and the non-updated ECU 22 can be maintained in the sleep mode, so that the power consumption for the update of the ECU 20 can be suppressed.
[0116] [1.6.3 Temporary Cluster Discarding Process] FIG. 12 is a flowchart showing details of the temporary cluster discarding process S300 in FIG. 7. In the control message, since the data fields assigned for cluster settings are finite, the number of clusters that can be set is limited. For example, since the data fields F1 and F2 shown in FIGS. 6 and 11 are 1 byte (8 bits), the upper limit of the number of clusters that can be set is 8. Therefore, after the update of the in-vehicle device 10 is completed, the in-vehicle device 10 discards the temporary cluster set in cluster C8 and makes it possible to set a new temporary cluster in cluster C8.
[0117] After the update process S200, the control unit 12 discards the setting of the temporary cluster by setting all the values in the row of cluster C8 in the cluster information T1a shown in FIG. 9 to "0" (step S311). As a result, the cluster information T1a becomes the cluster information T1 shown in FIG. 4. When, for example, the ECU21 is newly changed to belong to the cluster C2 by the first update data D1, the change is maintained as it is. That is, the control unit 12 returns only the value of the temporary cluster in the updated cluster information T1a to the state of the cluster information T1.
[0118] Next, the control unit 12 distributes the discard information Y3 for discarding the setting of the temporary cluster to the ECUs 21, 22, 24, and 25 belonging to the cluster C1 (steps S312 and S313). For example, the control unit 12 transmits the cluster information T2 to the ECU 21 (step S312) and transmits the cluster information T3 to the ECU 22 (step S313).
[0119] When the ECU 21 receives the cluster information T2 as the discard information Y3, the ECU 21 rewrites the cluster information T2a stored in the register 75 with the cluster information T2 to execute a new cluster setting that does not include the temporary cluster (step S321). That is, the bits corresponding to the temporary cluster in the cluster information T2a are changed from "1" to "0". By this cluster setting, the ECU 21 no longer belongs to the temporary cluster. When the rewriting of the register 75 is completed in the ECU 21, the ECU 21 transmits a completion notification to the in-vehicle device 10 (step S322).
[0120] When the ECU 22 receives the cluster information T3 as the discard information Y3, it executes a new cluster setting without including the temporary cluster by rewriting the cluster information T3a stored in the register 75 with the cluster information T3 (step S331). When the rewriting of the register 75 is completed in the ECU 22, the ECU 22 transmits a completion notice to the in-vehicle device 10 (step S332).
[0121] Note that when the rewriting of the register 75 in the ECU 22 is not executed in the temporary cluster formation step S100 (that is, when the execution of steps S115, S131, and S132 is omitted), the in-vehicle system 1 may omit the execution of steps S313, S331, and S332.
[0122] Thus, the temporary cluster discard step S300 ends. By discarding the temporary cluster settings after the update step S200, the temporary cluster can be dynamically set among the limited number of clusters. For example, when update data targeting other clusters (for example, clusters C2 and C3) is continuously distributed, the processes of steps S100, S200, and S300 can be continuously executed.
[0123] [2. Variation Example] Hereinafter, a variation example of the embodiment will be described. In the variation example, the same components as those in the above embodiment are denoted by the same reference numerals, and the description thereof is omitted.
[0124] [2.1 Addition of ECU] FIG. 13 is a diagram showing a state in which one new ECU 20 is added to the in-vehicle system 1. The new ECU 20 is referred to as ECU 26. The ECU 26 is an ECU belonging to the cluster C1 after the addition.
[0125] For example, consider a case where the ignition switch of vehicle V1 is off and ECU26 is added while all ECUs 20 belonging to cluster C1 are in the sleep mode. In this case, for example, with the addition of ECU26, the ECUs 20 belonging to cluster C1 may be updated. However, when the update is executed by the control method according to the above embodiment, since the non-updated ECU22 is maintained in the sleep mode in the update process S200, the non-updated ECU22 cannot detect the addition of ECU26.
[0126] Therefore, when a new ECU26 is added to cluster C1 prior to the distribution of the first update data D1, the control unit 12 of this modification example acquires additional information Y4, which is information regarding the new ECU26, before the new ECU26 is added. Then, prior to the distribution of the first update data D1, the control unit 12 distributes the additional information Y4 to the plurality of ECUs 20 belonging to cluster C1.
[0127] Thereby, before distributing the first update data D1, the information regarding ECU26 can be transmitted in advance to the ECUs 20 belonging to cluster C1. Thus, the non-updated ECU22, which remains in the sleep mode when the first update data D1 is distributed, can detect in advance that ECU26 will be added. Thereby, the reliability of the in-vehicle system 1 can be improved.
[0128] FIG. 14 is a flowchart showing the control method according to the modification example. The in-vehicle device 10 first acquires additional information Y4 (step S411). The additional information Y4 is provided to the in-vehicle device 10 together with the first update data D1 from, for example, an external device 61, a diagnostic device 62, or a recording medium 17. The additional information Y4 includes, for example, information for identifying ECU26 (e.g., the address of ECU26) and information regarding the cluster to which ECU26 belongs (e.g., the cluster number).
[0129] Before the ECU 26 is added, the in-vehicle device 10 distributes additional information Y4 to the ECU 20 belonging to the cluster C1 (the cluster to which the ECU 26 is planned to belong) via the communication bus 30 (step S412). For example, the in-vehicle device 10 performs step S412 in a state where the ECU 20 belonging to the cluster C1 is in the normal mode. Specifically, the in-vehicle device 10 distributes the additional information Y4 in a state where the ignition switch of the vehicle V1 is turned on.
[0130] The ECU 20 (including the non-updated ECU 22) belonging to the cluster C1 stores the received additional information Y4 in the storage unit 74 respectively. Thereby, the ECU 20 belonging to the cluster C1 can detect in advance information regarding the ECU 26 that is newly planned to belong to the cluster C1.
[0131] Subsequently, the ECU 26 is actually added to the in-vehicle system 1 (step S421). For example, the ECU 26 is connected to the communication bus 32. When the connection is completed, the ECU 26 transmits an addition completion notification to the in-vehicle device 10 (step S422).
[0132] Thereafter, the in-vehicle system 1 executes a temporary cluster formation process S100 and an update process S200. The ECU 26 may be an updated ECU updated by the first update data D1 or a non-updated ECU not updated by the first update data D1.
[0133] After receiving the addition completion notification in step S422, when the ECU 20 belonging to the cluster C1 wakes up respectively, the in-vehicle device 10 transmits addition completion information Y5 indicating that the addition of the ECU 26 is completed to the ECU 20 belonging to the cluster C1 (step S413).
[0134] The transmission timing of the additional completion information Y5 may differ depending on the timing at which the ECU 20 wakes up. For example, in the case of the updated ECUs 21, 24, and 25, in order to wake up when setting the temporary cluster in the temporary cluster formation step S100 or when performing the update in the update step S200, the in-vehicle device 10 transmits the additional completion information Y5 to the updated ECUs 21, 24, and 25 at that time.
[0135] In the case of the non-updated ECU 22, when setting the temporary cluster in the temporary cluster formation step S100, since the non-updated ECU 22 enters the normal mode at that time, it may transmit the additional completion information Y5. However, when the non-updated ECU 22 is not woken up in the temporary cluster formation step S100 (when steps S115, S131, and S132 in FIG. 8 are omitted), the non-updated ECU 22 remains in the sleep mode. Therefore, the in-vehicle device 10 may distribute the additional completion information Y5 to the ECUs 21, 22, 24, and 25 in a state where the ignition switch of the vehicle V1 is turned on and all the ECUs 20 belonging to the cluster C1 are in the normal mode.
[0136] [2.2 Notification of Update Content to Non-Updated ECU] In the above-described embodiment, the non-updated ECU 22 is maintained in the sleep mode in the update step S200. Therefore, the non-updated ECU 22 cannot know the update content of the updated ECU 21. For example, when the update content of the updated ECU 21 affects the operation of the non-updated ECU 22, it is preferable for the non-updated ECU 22 to grasp the update content in order to prevent malfunctions of the in-vehicle system 1 even if there is no update to the program of the non-updated ECU 22 itself.
[0137] Here, when data is transmitted from the ECU 20 connected to the communication bus 31 to the ECU 20 connected to a different communication bus 32, since the data passes through the in-vehicle device 10, the in-vehicle device 10 can stop the data from being transmitted to the communication bus 32 so that data that causes a malfunction in the ECU 20 connected to the communication bus 32 is not transmitted. On the other hand, when the updated ECU 21 and the non-updated ECU 22 are mixed in the same communication bus 31, the data transmitted from the updated ECU 21 to the communication bus 31 reaches the non-updated ECU 22 as it is. Therefore, the stopper function of the in-vehicle device 10 does not work, and there is a high possibility that a malfunction will occur in the operation of the non-updated ECU 22.
[0138] Therefore, when the updated ECU 21 and the non-updated ECU 22 are mixed in the same communication bus 31, the control unit 12 according to this modification collects the update contents of the updated ECU 21 by the first update data D1 and stores them in the storage unit 13. Then, after the updated ECU 21 is updated by the first update data D1, when the non-updated ECU 22 (the first non-updated ECU) connected to the same communication bus 31 as the updated ECU 21 enters the normal mode, the control unit 12 notifies the non-updated ECU 22 of the update contents by the first update data D1 of the updated ECU 21.
[0139] Thereby, it is possible to suppress the update contents of the updated ECU 21 from causing a malfunction in the operation of the non-updated ECU 22.
[0140] [2.3 Temporary Cluster in a Competitive State] In the above embodiment, the temporary cluster is set to the "empty" cluster C8. However, in reality, there may be no "empty" cluster C8. In this case, for example, it is conceivable to temporarily set a cluster with low usage frequency or the like as a temporary cluster.
[0141] For example, consider the case where, between the temporary cluster formation step S100 and the temporary cluster deletion step S300, the cluster C3 is temporarily changed to a temporary cluster to which only the updated ECUs 21, 24, and 25 updated by the first update data D1 belong.
[0142] In this case, before the temporary cluster is set, the ECU 22 is switched to the normal mode by a control message (hereinafter referred to as "first control message Mx1") including a data field enabling cluster C3. On the other hand, after the temporary cluster is set, since the ECU 22 no longer belongs to cluster C3, the ECU 22 cannot be switched to the normal mode by the first control message Mx1.
[0143] Note that, whether before or after the temporary cluster is set, the ECU 22 is switched to the normal mode by a control message (hereinafter referred to as "second control message Mx2") including a data field enabling cluster C2.
[0144] In such a case, even if an event occurs that wakes up the ECU 22 by cluster C3, the ECU 22 cannot be woken up by the setting of the temporary cluster. For example, consider the case where cluster C3 is originally set so that the ECU 20 operating in association with the unlocking of the door of vehicle V1 belongs to it. Specifically, the ECU 21 is an ECU for receiving a release signal indicating that the door of vehicle V1 has been unlocked from a sensor, and the ECU 22 is an ECU for controlling an actuator for opening the mirror of vehicle V1 outward in association with the unlocking of the door of vehicle V1.
[0145] At this time, when the ECU 21 receives the release signal, it transmits the first control message Mx1 to the communication bus 31 to try to wake up the ECU 20 operating in association with the unlocking of the door including the ECU 22. However, when a temporary cluster is set for cluster C3, the ECU 22 that should originally be woken up by the first control message Mx1 does not wake up, and problems such as the mirror of vehicle V1 not opening may occur.
[0146] Therefore, in this modified example, even when the setting of the temporary cluster conflicts with the original cluster, in order to suppress the malfunction in the in-vehicle system 1, the in-vehicle device 10 wakes up the ECU 22 that has stopped being woken up by the first control message Mx1 by another control message.
[0147] FIG. 15 is a flowchart showing a control method according to a modified example. After the temporary cluster formation step S100 and before the temporary cluster destruction step S300, the ECU 21 transmits the first control message Mx1 to the communication bus 31. The first control message Mx1 is received by the ECU 22 via the communication bus 31 (step S521) and is also received by the in-vehicle device 10 (step S522). As described above, after the setting of the temporary cluster, the ECU 22 does not wake up even when receiving the first control message Mx1.
[0148] For example, during the temporary cluster formation step S100, the control unit 12 causes the storage unit 13 to store information (change information) regarding the portion of the cluster information T1 that has been changed from "1" to "0" due to the setting of the temporary cluster. Then, after step S522, the control unit 12 determines whether the temporary cluster enabled by the first control message Mx1 conflicts with the original cluster (step S511).
[0149] Specifically, when receiving the first control message Mx1, the control unit 12 determines whether the first control message Mx1 is addressed to the ECU 20 whose cluster information T1 has been changed from "1" to "0" due to the setting of the temporary cluster. That is, it is determined whether the destination of the first control message Mx1 is the ECU 20 (conflicting ECU) that was woken up by the first control message Mx1 before the setting of the temporary cluster but is no longer woken up by the first control message Mx1 due to the setting of the temporary cluster.
[0150] When the control unit 12 determines as a result of the determination that the destination of the first control message Mx1 is a competing ECU, it transmits a second control message Mx2 to the competing ECU (in this example, ECU22) (step S512). ECU22 switches from the sleep mode to the normal mode upon receiving the second control message Mx2 (step S531).
[0151] Next, while ECU22 is in the normal mode by the second control message Mx2, the control unit 12 transmits activation information Y6 to ECU22 (step S513). Here, the activation information Y6 is information for changing the cluster setting of ECU22 so that the first control message Mx1 switches ECU22 to the normal mode.
[0152] For example, in register 75 of ECU22, if cluster information T3 (111···0) is stored before the temporary cluster formation step S100 and cluster information T3b (for example, 110···0) is stored after the temporary cluster formation step S100, the activation information Y6 is information for changing the "0" in the third bit, which is a temporary cluster in the cluster information T3b, to "1", such as cluster information T3c (111···0).
[0153] ECU22 newly sets the cluster by rewriting the cluster information in register 75 based on the activation information Y6 (step S532). As a result, ECU22 can be woken up by a control message including a data field in which the temporary cluster (cluster C3) is valid and perform various controls.
[0154] Subsequently, the in-vehicle device 10 transmits the first control message Mx1 to ECU22 (step S514). Note that the in-vehicle device 10 may instruct ECU21 to retransmit the first control message Mx1. In this case, the first control message Mx1 is transmitted from ECU21 that has received the instruction to ECU22.
[0155] Based on the first control message Mx1, the ECU 22 executes predetermined control (step S533). The predetermined control is, for example, control to open the mirror of the vehicle V1. After executing the predetermined control and before executing the update process S200, the in-vehicle device 10 transmits invalidation information Y7 to the ECU 22 (step S515).
[0156] Here, the invalidation information Y7 is information for changing the cluster setting of the ECU 22 so that the first control message Mx1 does not switch the ECU 22 to the normal mode. For example, the invalidation information Y7 is information for returning to "0" the bit that was temporarily changed from "0" to "1" by the activation information Y6, such as the third bit of the cluster information T3c (111···0).
[0157] Based on the invalidation information Y7, the ECU 22 rewrites the cluster information of the register 75 to newly set the cluster (step S534). As a result, the ECU 22 will not wake up by the control message including the data field in which the temporary cluster (cluster C3) is valid. Thereafter, the ECU 22 switches to the sleep mode (step S535).
[0158] As described above, by temporarily changing the cluster setting of the ECU 22 that no longer wakes up due to the conflict of the temporary cluster, it is possible to execute predetermined control in the ECU 22. Thereby, even when the number of clusters is limited and a temporary cluster is set in an already used cluster, it is possible to suppress the occurrence of problems in the in-vehicle system 1.
[0159] Also, after the predetermined control in the ECU 22, by restoring the cluster setting of the ECU 22 to its original state, it is possible to keep the ECU 22 in the sleep mode in the update process S200, so that it is possible to suppress the power consumption in the in-vehicle system 1 during the update.
[0160] [2.4 Conflict Avoidance of Temporary Clusters] According to the control method shown in FIG. 15, even when a conflict occurs in the temporary cluster, the ECU 22 can be operated. However, in the example of FIG. 15, it takes a required time TM1 from when the first control message Mx1 is transmitted from the ECU 21 to the ECU 22 until a predetermined control is performed. If there is no setting of the temporary cluster in the cluster C3, a predetermined control is executed immediately after the first control message Mx1 is transmitted from the ECU 21 to the ECU 22 (that is, without going through the steps S511, S512, S531, S513, D532, S514 in FIG. 15). Therefore, the ECU 22 can respond faster when there is no conflict in the temporary cluster. For this reason, it is preferable not to set a temporary cluster for a cluster that requires faster control.
[0161] For example, the control message includes an immediacy message that requires immediate control and a non-immediacy message that does not require immediate control as much as the immediacy message. The immediacy message is, for example, a control message in which the allowable time from when the ECU 21 transmits a control message addressed to the ECU 22 until the ECU 22 executes processing based on the control message is less than the first threshold Th1.
[0162] The control executed by the immediacy message is, for example, a control to unlock the door of the vehicle V1. Since the user of the vehicle V1 is likely to feel discomfort if the time for waiting for the door to be unlocked is long, immediate control is required for the door unlock control. Also, the control executed by the immediacy message may be a control to drive the seat motor of the vehicle V1. Since the user is likely to feel discomfort if there is a delay, immediate control is required for this control.
[0163] Also, the control executed by the immediacy message may be a control to turn on the headlights of the vehicle V1, or a control to turn on the hazard of the vehicle V1, or a control to operate the wiper of the vehicle V1. Since these controls are related to the safety of the vehicle V1, immediate control is required.
[0164] In addition, the control executed by the immediate message may be security control (for example, glass breakage detection, reporting of theft prevention alarm, etc.) or illumination control. If there is a delay in security control, the risk of theft of the vehicle V1 may increase, so immediate control is required. Also, if there is a deviation in the blinking of the lights of the vehicle V1, the person who sees the lights may feel uncomfortable, so immediate control is required.
[0165] A non-immediate message is, for example, a control message in which the allowable time from when the ECU 21 sends a control message addressed to the ECU 22 until the ECU 22 executes processing based on the control message is equal to or greater than the first threshold value Th1.
[0166] The control executed by the non-immediate message is, for example, control to open the mirror when the door of the vehicle V1 is unlocked. After the door of the vehicle V1 is unlocked, it takes some time until the vehicle V1 starts, for example, until the user fastens the seat belt, so even if there is a slight delay until the mirror opens, the user is unlikely to feel discomfort.
[0167] Among the plurality of ECUs 20, the ECU 20 that transmits and receives immediate messages is predetermined, and the storage unit 13 stores information regarding the ECU 20 that transmits and receives immediate messages. Then, when setting the temporary cluster, the control unit 12 does not set a temporary cluster for the cluster in which the ECU 20 that transmits and receives immediate messages is set to "1". As a result, only non-immediate messages can become the first control message. Thereby, it is possible to suppress a delay in control with a short allowable time.
[0168] [3. Supplementary Note] Regarding the above-described embodiments and various modifications, at least a part of them may be arbitrarily combined with each other. Also, the embodiments and modifications disclosed this time should be considered as illustrative in all respects and not restrictive. The scope of the present disclosure is indicated by the claims, and it is intended that all modifications within the meaning and scope equivalent to the claims are included.
Explanation of Reference Numerals
[0169] 1 Vehicle-mounted system 10 Vehicle-mounted device 11 Microcontroller unit (MCU) 12 Control unit 13 Storage unit 14 Reading unit 15a Transceiver 15b Transceiver 15c Transceiver 15d Transceiver 16 Bus 17 Recording medium 20 ECU 21 ECU (Updated ECU) 22 ECU (Non-updated ECU, First non-updated ECU, Competing ECU) 23 ECU (Updated ECU) 24 ECU (Updated ECU) 25 ECU (Updated ECU) 26 ECU (New ECU) 30 Communication bus 31 Communication bus 32 Communication bus 41 Communication line 42 Communication line 50 Communication device 61 External device 62 Diagnostic device 71 Microcontroller unit (MCU) 72 Transceiver 73 Control unit 74 Storage unit 75 Register V1 Vehicle N1 Network Cluster C1 (First Cluster) Cluster C2 Cluster C3 Cluster C8 Cluster Information T1 Cluster Information T1a Cluster Information T2 Cluster Information T2a Cluster Information T3 Cluster Information T3a Cluster Information T3b Cluster Information T3c Data Field F1 Data Field F2 First Update Data D1 Control Message M1 First Control Message Mx1 Second Control Message Mx2 Update Information Y1 Setting Information Y2 Discard Information Y3 Additional Information Y4 Additional Completion Information Y5 Activation Information Y6 Deactivation Information Y7 Required Time TM1 First Threshold Th1
Claims
1. An in-vehicle device that distributes update data provided from outside the vehicle to a plurality of ECUs connected via a communication bus, wherein the in-vehicle device includes a control unit, the plurality of ECUs each belong to at least one of a plurality of clusters, in the control message received from the communication bus, when the cluster to which the own ECU belongs is invalid, it enters a sleep mode in which the function is restricted more than in the normal mode to suppress power consumption, and when the cluster to which the own ECU belongs is valid, it enters the normal mode, the control unit prior to distributing first update data which is the update data targeted at a first cluster among the plurality of clusters, distributes setting information for setting a temporary cluster to the plurality of ECUs belonging to the first cluster, the temporary cluster including the update ECUs updated by the first update data and not including the non-update ECUs not updated by the first update data, when distributing the first update data, distributes the control message in which the first cluster is made invalid and the temporary cluster is made valid, to the plurality of ECUs. In-vehicle device.
2. further includes a storage unit that stores cluster information associating the plurality of ECUs with the clusters to which the plurality of ECUs respectively belong, the control unit determines, based on the first update data or update information provided from outside the vehicle prior to the provision of the first update data, and the cluster information, whether each of the plurality of ECUs belonging to the first cluster is the update ECU or the non-update ECU. The in-vehicle device according to claim 1.
3. after distributing the first update data, the control unit distributes discard information for discarding the setting of the temporary cluster to the plurality of ECUs belonging to the first cluster. The in-vehicle device according to claim 2.
4. the control unit when a new ECU belonging to the first cluster is added to the communication bus prior to the distribution of the first update data, acquires additional information which is information regarding the new ECU before the new ECU is added, and prior to the distribution of the first update data, distributes the additional information to the plurality of ECUs belonging to the first cluster. The in-vehicle device according to claim 1.
5. the control unit While the control message that enables the first cluster has set the plurality of ECUs belonging to the first cluster to the normal mode, the setting information is distributed to the plurality of ECUs belonging to the first cluster. The in-vehicle device according to claim 1.
6. After the update ECU is updated with the first update data, when the first non-update ECU, which is a non-update ECU connected to the same communication bus as the update ECU, enters the normal mode, the control unit notifies the first non-update ECU of the update content of the update ECU based on the first update data. The in-vehicle device according to claim 5.
7. Before the setting of the temporary cluster, the plurality of ECUs are switched to the normal mode by a first control message. After the setting of the temporary cluster, they are not switched to the normal mode by the first control message, but include competing ECUs that are switched to the normal mode by a second control message different from the first control message. The control unit, When the control unit receives the first control message addressed to the competing ECU after the setting of the temporary cluster, the control unit transmits the second control message to the competing ECU. While the competing ECU is in the normal mode by the second control message, the control unit transmits activation information for setting the first control message to switch the competing ECU to the normal mode to the competing ECU. After transmitting the activation information, the control unit transmits the first control message to the competing ECU. The in-vehicle device according to claim 1.
8. After transmitting the activation information and the first control message to the competing ECU, the control unit transmits deactivation information for setting the first control message not to switch the competing ECU to the normal mode to the competing ECU. The in-vehicle device according to claim 7.
9. The control message, An immediacy message in which the allowable time from when the control unit receives the control message until control based on the control message is executed in the competing ECU is less than a first threshold value, and A non-immediacy message in which the allowable time is greater than or equal to the first threshold value, Including The first control message is the non-immediacy message. The in-vehicle device according to claim 7 or claim 8.
10. The in-vehicle device according to any one of claims 1 to 8, and A plurality of the ECUs connected to the in-vehicle device via the communication bus, An in-vehicle system comprising the same.
11. A control method for controlling an in-vehicle device that distributes update data provided from outside the vehicle to a plurality of ECUs connected via a communication bus, The plurality of ECUs, Each belong to at least one cluster among a plurality of clusters, In the control message received from the communication bus, when the cluster to which the own ECU belongs is invalid, it becomes a sleep mode in which the function is restricted more than in the normal mode to suppress power consumption, and when the cluster to which the own ECU belongs is valid, it becomes the normal mode, The control method, Prior to the distribution of first update data, which is the update data targeted at a first cluster among the plurality of clusters, first step of distributing setting information for setting a temporary cluster to a plurality of the ECUs belonging to the first cluster, where the update ECU updated by the first update data belongs and the non-update ECU not updated by the first update data does not belong, Second step of distributing, to the plurality of ECUs, the control message in which the first cluster is made invalid and the temporary cluster is made valid when distributing the first update data, A control method comprising the same.
12. A computer program for controlling an in-vehicle device that distributes update data provided from outside the vehicle to a plurality of ECUs connected via a communication bus, The plurality of ECUs, Each belong to at least one cluster among a plurality of clusters, In the control message received from the communication bus, when the cluster to which the own ECU belongs is invalid, it becomes a sleep mode in which the function is restricted more than in the normal mode to suppress power consumption, and when the cluster to which the own ECU belongs is valid, it becomes the normal mode, The computer program causes a computer to, Before delivering first update data, which is the update data targeted at a first cluster among the plurality of clusters, to a plurality of ECUs belonging to the first cluster, first step of delivering setting information for setting a temporary cluster, to which updated ECUs updated by the first update data belong and non-updated ECUs not updated by the first update data do not belong, to the plurality of ECUs belonging to the first cluster; Second step of delivering, to the plurality of ECUs, a control message that invalidates the first cluster and validates the temporary cluster when delivering the first update data; A computer program for causing the above to be executed.
Citation Information
Patent Citations
Management system and diagnosis system
JP2014000872A
System management apparatus
JP2019128695A
Network control system and relay device
JP2019186605A
Center device, vehicle information communication system, distribution package transmission method, and distribution package transmission program
JP2020027625A
Communication system
JP2021129245A