On-vehicle device, update processing method and on-vehicle update system

Abstract

To provide an on-vehicle device that performs a process for obtaining an update program transmitted from an external server outside a vehicle to update a program of an on-vehicle ECU mounted on the vehicle.SOLUTION: An on-vehicle device comprises a control unit that performs a process relating to an update program. On-vehicle ECUs include: a two-side waiting ECU having a first storage region and a second storage region as regions where the update program is stored; and a one-side waiting ECU having only the first storage region. The control unit obtains vehicle state information showing a state of a vehicle, identifies one or more on-vehicle ECUs to which the update program is transmitted, in accordance with the obtained vehicle state information, and transmits the update program to the identified one or more on-vehicle ECUs.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to an in-vehicle device, an update processing method, and an in-vehicle update system. [Background technology]

[0002] A vehicle is equipped with an on-board ECU (Electronic Control Unit) for controlling on-board devices such as a power train system such as engine control and a body system such as air conditioning control. The on-board ECU includes an arithmetic processing unit such as an MPU (Micro Processing Unit), a rewritable non-volatile storage unit such as a RAM, and a communication unit for communicating with other on-board ECUs, and controls the on-board devices by reading and executing a control program stored in the storage unit. Furthermore, a relay device having a wireless communication function is mounted on the vehicle, and the vehicle can communicate with a program providing device connected to a network outside the vehicle via the relay device, download (receive) a control program for the on-board ECU from the program providing device, and update the control program for the on-board ECU (see, for example, Patent Document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2017-97851 A Summary of the Invention [Problem to be solved by the invention]

[0004] However, the relay device of Patent Document 1 does not take into consideration the point of identifying one or more in-vehicle ECUs to which the update program is to be transmitted, based on the vehicle state information, and transmitting the update program.

[0005] An object of the present invention is to provide an in-vehicle device or the like that can efficiently perform processing related to an update program. [Means for solving the problem]

[0006] An in-vehicle device according to one embodiment of the present disclosure is an in-vehicle device that acquires an update program transmitted from an external server outside the vehicle and performs processing to update a program of an in-vehicle ECU installed in the vehicle, and is equipped with a control unit that performs processing related to the update program, and the in-vehicle ECU includes a two-sided ECU having a first memory area and a second memory area as areas for storing the update program, and a single-sided ECU having only the first memory area, and the control unit acquires vehicle state information indicating the state of the vehicle, and depending on the acquired vehicle state information, identifies one or more in-vehicle ECUs to which the update program is to be sent, and transmits the update program to the identified one or more in-vehicle ECUs. Effect of the Invention

[0007] According to one aspect of the present disclosure, it is possible to provide an in-vehicle device or the like that efficiently performs processing related to an update program. [Brief description of the drawings]

[0008] [Figure 1] 1 is a schematic diagram illustrating a configuration of an in-vehicle update system according to a first embodiment. [Diagram 2] FIG. 2 is a block diagram illustrating a configuration of an in-vehicle device. [Diagram 3] FIG. 2 is an explanatory diagram illustrating an example of ECU management information (ECU management table). [Figure 4] FIG. 2 is an explanatory diagram illustrating an example of scene information (vehicle scene table). [Diagram 5] 4 is a flowchart illustrating a process of a control unit of an in-vehicle device. [Figure 6] FIG. 11 is an explanatory diagram illustrating an example of rewriting during charging or the like. [Figure 7] FIG. 11 is an explanatory diagram illustrating an example of rewriting during driving, etc. [Figure 8] FIG. 11 is an explanatory diagram illustrating an example of rewriting during maintenance or the like. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] [Description of the embodiments of the present disclosure] First, embodiments of the present disclosure will be listed and described. In addition, at least some of the embodiments described below may be arbitrarily combined.

[0010] (1) An in-vehicle device according to one embodiment of the present disclosure is an in-vehicle device that acquires an update program transmitted from an external server outside the vehicle and performs processing to update a program of an in-vehicle ECU installed in the vehicle, and is equipped with a control unit that performs processing related to the update program, and the in-vehicle ECU includes a dual-sided ECU having a first memory area and a second memory area as areas for storing the update program, and a single-sided ECU having only the first memory area, and the control unit acquires vehicle state information indicating a state of the vehicle, and in accordance with the acquired vehicle state information, identifies one or more in-vehicle ECUs to which the update program is to be sent, and transmits the update program to the identified one or more in-vehicle ECUs.

[0011] In this embodiment, the in-vehicle device acquires an update program stored in an external server (OTA (Over The Air) server), temporarily stores the program in a storage unit, and then functions as an OTA master that transmits the update program to an in-vehicle ECU (an update target ECU) that is a destination of the update program. The in-vehicle device (OTA master) can recognize the existence of a new update program by campaign information notified from the external server. When software of a plurality of in-vehicle ECUs needs to be updated substantially simultaneously (at the same timing), update software groups for the plurality of in-vehicle ECUs (an update target ECU group) may be stored in an external server, for example, as an archived package. In this case, the in-vehicle device (OTA master) may constantly acquire the package based on campaign information (information related to program update) notified from the external server, and temporarily (primarily) store the package in a storage unit. The control unit of the in-vehicle device acquires vehicle state information indicating the state of the vehicle (scenes such as charging state, running state, maintenance state, etc.) by acquiring communication data such as various messages via the in-vehicle network, and identifies one or more in-vehicle ECUs to which the update program is to be transmitted according to the acquired vehicle state information (scene). The control unit of the in-vehicle device performs re-processing on the target in-vehicle ECU group (update target ECU group) according to a comparison with the updatable ECUs (updatable ECU group) defined in the vehicle state information (vehicle scene). Even if the package is acquired from an external server in this way, the control unit of the in-vehicle device determines the time to start the re-processing according to the vehicle state information (vehicle scene), and stores the package in the storage unit until the re-processing is started. Thus, the control unit of the in-vehicle device may store multiple packages in the storage unit. When the update target ECU group is included in the updatable ECU group corresponding to the vehicle state information (update target ECU group ⊂ updatable ECU group), the control unit of the in-vehicle device transmits the update program to each of the update target ECUs included in the update target ECU group.In-vehicle ECUs that can be the update target ECU include a dual-sided ECU having a dual-sided storage unit with a first storage area and a second storage area as areas for storing the update program, and a single-sided ECU having a single-sided storage unit with only the first storage area. Therefore, it is not necessary to configure all in-vehicle ECUs with only dual-sided ECUs, which relatively increases the production cost, and by including one or more single-sided ECUs, the overall production cost required for the in-vehicle ECUs mounted on the vehicle can be reduced. In this way, the control unit of the in-vehicle device identifies one or more in-vehicle ECUs to which the update program is to be sent according to the vehicle state information and sends the update program, so that the process related to the update program can be performed efficiently.

[0012] (2) In one embodiment of the in-vehicle device of the present disclosure, the vehicle is equipped with a shared storage device shared by multiple single-sided ECUs, and when the vehicle status information indicates a maintenance status, the control unit transmits the update program to the shared storage device connected to the single-sided ECU identified as the destination.

[0013] In this embodiment, at least two of the single-face ECUs (vehicle-mounted ECUs) mounted on a vehicle are provided with (connected to) a shared storage device (shared memory). That is, the vehicle is equipped with a shared storage device (shared memory) shared by two or more single-face ECUs. The shared storage device is connected to each of the two single-face ECUs by a connection form and cable conforming to USB (Universal Serial Bus) or SPI (Serial Peripheral Interface), is communicatively connected to each of the two single-face ECUs, and functions as a storage area (shared memory) shared by the two single-face ECUs. The shared storage device may include an exclusive area that can be exclusively accessed by each of the connected single-face ECUs (an area that can be accessed only by one single-face ECU and an area that can be accessed only by the other single-face ECU) and a shared area that can be accessed by both of the two single-face ECUs. When the vehicle state information indicates a maintenance state, the control unit of the in-vehicle device transmits an update program to a shared storage device connected to a single-sided ECU (in-vehicle ECU) identified as a transmission destination. In this case, the control unit of the in-vehicle device indirectly transmits the update program to the shared storage device via the single-sided ECU (in-vehicle ECU) in which the shared storage device is provided. Since the in-vehicle ECU (single-sided ECU) mounted on the vehicle includes a shared storage device connected to a plurality of single-sided ECUs as an area for storing the update program, it is possible to avoid configuring all the in-vehicle ECUs only with two-sided ECUs, which relatively increases the production cost, and it is possible to reduce the overall production cost required for the in-vehicle ECUs mounted on the vehicle. Even if a single-sided ECU (in-vehicle ECU) to which a shared storage device (shared memory) is connected is identified as an ECU to be updated, the control unit of the in-vehicle device indirectly transmits the update program to the shared storage device, so that the process related to the update program can be efficiently performed.

[0014] (3) In one embodiment of the in-vehicle device according to the present disclosure, the state of the vehicle includes a charging state, a running state, a maintenance state, and a stopped state, and the control unit determines which state the vehicle is in based on the vehicle state information.

[0015] In this embodiment, the vehicle state information includes a charging state, a running state, a maintenance state, and a stopped state, and the control unit of the in-vehicle device identifies whether the current state of the vehicle is a charging state, a running state, a maintenance state, or a stopped state based on communication data such as various messages acquired via the in-vehicle LAN or various signals output from an in-vehicle device such as an IG switch. By defining the multiple states included in the vehicle state information in this way, the ECU to be updated can be specified in more detail, so that the process related to the update program can be performed efficiently.

[0016] (4) In an in-vehicle device according to one embodiment of the present disclosure, each of the in-vehicle ECUs is classified into the dual-sided ECU, the single-sided ECU, or an ECU equipped with the shared storage device based on an operation corresponding to the state of the vehicle, and ECU management information indicating the classification of each of the in-vehicle ECUs is stored in a memory unit in which the update program obtained from the external server is stored.

[0017] In this embodiment, each of the vehicle-mounted ECUs that may be updated is classified into a dual-sided ECU, a single-sided ECU, or an ECU equipped with a shared storage device based on the operation (function) corresponding to the vehicle state information. In the storage unit of the vehicle-mounted device, ECU management information indicating the classification of each vehicle-mounted ECU is stored, for example, in a table format (ECU management table). The operation (function) of the vehicle-mounted ECU includes, for example, function-limited driving control, charging control, minimum body control, body control, and other control. The function-limited driving control relates to, for example, control when some functions in the vehicle are abnormal and the vehicle is driven with some functions stopped or limited (evacuation driving control). The charging control relates to, for example, control related to charging when a storage battery mounted on the vehicle is charged while the vehicle is stopped (IG switch or power switch is off). The minimum body control relates to control related to various body actuators that is the minimum control required during vehicle operation. The body control is a control other than the above-mentioned minimum body control in the control of various body actuators, and is a control having a lower priority (ASIL: Automotive Safety Integrity Level) than the minimum body control in terms of the operation of the vehicle. The other control is a control other than the above-mentioned limited-function driving control, charging control, minimum body control, and body control, and is a control having a lower priority (ASIL) than the body control in terms of the operation of the vehicle. Therefore, from the viewpoint of priority (ASIL), the limited-function driving control has the highest priority, followed by the charging control, minimum body control, body control, and other control. Since each of the vehicle-mounted ECUs is defined in this way and classified into a two-sided ECU, a one-sided ECU, or an ECU equipped with a shared storage device based on the operation (function) according to the vehicle state information, it is possible to avoid configuring all the vehicle-mounted ECUs only with two-sided ECUs, which relatively increase the product cost (high product cost), and it is possible to reduce the overall product cost required for the vehicle-mounted ECUs mounted on the vehicle.

[0018] (5) In one embodiment of the in-vehicle device of the present disclosure, the memory unit stores scene information that defines an association between the vehicle state information and the in-vehicle ECU to which the update program is to be sent, and the control unit identifies one or more in-vehicle ECUs to which the update program is to be sent, based on the vehicle state information, by referring to the ECU management information and the scene information.

[0019] In this embodiment, the storage unit stores scene information on the in-vehicle ECUs to which the update program is to be sent, for example in a table format (vehicle scene table), in accordance with the operation (function) corresponding to the vehicle state information. The control unit of the in-vehicle device refers to the ECU management information (ECU management table) and the scene information (vehicle scene table) stored in the storage unit to identify one or more in-vehicle ECUs to which the update program is to be sent, and can efficiently perform processing related to the update program.

[0020] (6) An update processing method according to one aspect of the present disclosure is an update processing method that causes a computer to obtain an update program transmitted from an external server outside the vehicle and execute processing to update a program of an in-vehicle ECU installed in the vehicle, wherein the in-vehicle ECU includes a dual-sided ECU having a first memory area and a second memory area as areas for storing the update program, and a single-sided ECU having only the first memory area, and causes the computer to obtain vehicle state information indicating a state of the vehicle, identify one or more in-vehicle ECUs to which the update program is to be sent according to the obtained vehicle state information, and execute processing to send the update program to the identified one or more in-vehicle ECUs.

[0021] According to this aspect, it is possible to provide an update processing method that causes a computer to function as an in-vehicle device that efficiently performs processing related to update programs.

[0022] (7) An in-vehicle update system according to one embodiment of the present disclosure includes a plurality of in-vehicle ECUs mounted on a vehicle, and an in-vehicle device that acquires update programs transmitted from an external server outside the vehicle and performs processing to update the programs of the in-vehicle ECUs, wherein the in-vehicle device is equipped with a control unit that performs processing related to the update programs, and the in-vehicle ECUs include a two-sided ECU having a first memory area and a second memory area as areas for storing the update programs, and a single-sided ECU having only the first memory area, and the control unit of the in-vehicle device acquires vehicle state information indicating a state of the vehicle, identifies one or more in-vehicle ECUs to which the update programs are to be sent according to the acquired vehicle state information, and transmits the update programs to the identified one or more in-vehicle ECUs.

[0023] According to this aspect, it is possible to provide an in-vehicle update system including an in-vehicle device that efficiently performs processing related to the update program.

[0024] [Details of the embodiment of the present disclosure] The present disclosure will be specifically described based on the drawings showing the embodiments. An in-vehicle device 2 according to the embodiment of the present disclosure will be described below with reference to the drawings. Note that the present invention is not limited to these examples, but is indicated by the claims, and is intended to include all modifications within the meaning and scope equivalent to the claims.

[0025] (Embodiment 1) Hereinafter, an embodiment will be described with reference to the drawings. Fig. 1 is a schematic diagram showing the configuration of an in-vehicle update system S according to the first embodiment. Fig. 2 is a block diagram showing the configuration of an in-vehicle device 2. The in-vehicle update system S includes an external communication device 1 and an in-vehicle device 2 mounted on a vehicle C, and transmits an update program acquired from an external server S1 (program providing device, OTA server) connected via an external network to an in-vehicle ECU3 (Electronic Control Unit) mounted on the vehicle C.

[0026] The external server S1 is a computer such as a server connected to an external network such as the Internet or a public line network, has a storage unit such as a RAM (Random Access Memory), a ROM (Read Only Memory), or a hard disk, and corresponds to an external program providing device. The external server S1 stores in its storage unit programs or data for controlling the in-vehicle ECU 3, which have been created by a manufacturer of the in-vehicle ECU 3, etc. The programs or data are transmitted to the vehicle C as update programs, as described below, and are used to update the programs or data of the in-vehicle ECU 3 installed in the vehicle C. The external server S1 (program providing device) configured in this manner is also called an OTA (Over The Air) server.

[0027] The in-vehicle device 2 functions as an OTA master that transmits an update program acquired from the external server S1 to the in-vehicle ECU 3 to be updated, and transmits an activation instruction for applying the transmitted update program to the in-vehicle ECU 3. The in-vehicle ECU 3 mounted on the vehicle C acquires the update program transmitted by wireless communication from the external server S1 via the in-vehicle device 2, and applies the update program in response to the activation instruction (activation process), thereby updating (reprogramming) the program executed by its own ECU.

[0028] Hereinafter, the program will be described as including a program code including a control syntax and the like for the in-vehicle ECU 3 to perform processing, and an external file in which data referenced when the program code is executed is described. When transmitting an update program, the external file in which the program code and data are described is transmitted from the external server S1, for example, as an encrypted archive file. When transmitting the update program, the external server S1 generates a package including the update program, and transmits the generated package to the vehicle C. The package includes, for example, package information (campaign information) that is information related to the program update, information related to the in-vehicle ECU 3 to be updated (target information), and the update program to be applied to the in-vehicle ECU 3 to be updated.

[0029] The vehicle C is equipped with an external communication device 1, an in-vehicle device 2, and a plurality of in-vehicle ECUs 3 for controlling various in-vehicle devices. The external communication device 1 and the in-vehicle device 2 are communicatively connected by a harness such as a serial cable. The in-vehicle device 2 and the in-vehicle ECUs 3 are communicatively connected by an in-vehicle network 5 that supports a communication protocol such as CAN (Control Area Network) or Ethernet (registered trademark).

[0030] The exterior-vehicle communication device 1 includes an exterior-vehicle communication unit (not shown) and an input / output I / F (not shown) (interface) for communicating with the in-vehicle device 2. The exterior-vehicle communication unit is a communication device for wireless communication using a mobile communication protocol such as LTE (registered trademark), 4G, 5G, or WiFi (registered trademark), and transmits and receives data to and from an external server S1 via an antenna 11 connected to the exterior-vehicle communication unit. The communication between the exterior-vehicle communication device 1 and the external server S1 is performed via an external network such as a public line network or the Internet.

[0031] The input / output I / F of the extra-vehicle communication device 1 is a communication interface for, for example, serial communication with the in-vehicle device 2. The extra-vehicle communication device 1 and the in-vehicle device 2 communicate with each other via a harness such as a serial cable connected between the input / output I / Fs. In this embodiment, the extra-vehicle communication device 1 is a device separate from the in-vehicle device 2, and these devices are communicatively connected by the input / output I / F or the like, but this is not limited thereto. The extra-vehicle communication device 1 may be built into the in-vehicle device 2 as one component of the in-vehicle device 2. Alternatively, the extra-vehicle communication device 1 and the in-vehicle device 2 may be connected by an in-vehicle network 5 such as a CAN.

[0032] The in-vehicle device 2 includes a control unit 20, a storage unit 21, an input / output I / F 22, and an in-vehicle communication unit 23. The in-vehicle device 2 is configured to acquire, from the outside-vehicle communication device 1, an update program (package) that the outside-vehicle communication device 1 has received from the external server S1 via wireless communication, and transmit the update program to a predetermined in-vehicle ECU 3 (the in-vehicle ECU 3 to be updated) via the in-vehicle network 5. That is, the in-vehicle device 2 functions as an OTA master (repro master) that controls program updates in the in-vehicle ECU 3 to be updated.

[0033] The in-vehicle device 2 is a gateway (in-vehicle relay device) that manages a plurality of buses (segments) and relays communication between the in-vehicle ECUs 3 between these buses (segments). That is, the in-vehicle device 2 is connected to each of the communication lines that constitute the plurality of buses (segments), and the in-vehicle network 5 is configured by the plurality of communication lines (segments) aggregated by the in-vehicle device 2. The in-vehicle device 2 functions as a CAN gateway in relaying the CAN protocol, and functions as a layer 2 switch or layer 3 switch in relaying the TCP / IP protocol. The in-vehicle device 2 may be a PLB (Power Lan Box) that functions as a power distribution device that distributes and relays power output from a power supply device such as a secondary battery and supplies power to an in-vehicle device such as an actuator connected to the in-vehicle device itself, in addition to relaying communication. Alternatively, the in-vehicle device 2 may be an integrated ECU that is configured by a central control device such as a vehicle computer and performs overall control of the vehicle C.

[0034] The control unit 20 is composed of a CPU (Central Processing Unit) or an MPU (Micro Processing Unit), and is configured to perform various control processing, calculation processing, etc. by reading and executing a control program P (program product) and data pre-stored in the memory unit 21.

[0035] The storage unit 21 is configured with a volatile memory element such as a RAM (Random Access Memory) or a non-volatile memory element such as a ROM (Read Only Memory), an EEPROM (Electrically Erasable Programmable ROM), or a flash memory. The storage unit 21 stores in advance a control program P and data to be referenced during processing. The control program P (program product) stored in the storage unit 21 may be a control program P (program product) read from a recording medium M readable by the in-vehicle device 2. Alternatively, the control program P may be downloaded from an external computer (not shown) connected to a communication network (not shown) and stored in the storage unit 21.

[0036] The input / output I / F 22 is a communication interface for, for example, serial communication, similar to the input / output I / F of the exterior communication device 1. The in-vehicle device 2 is communicatively connected to the exterior communication device 1, a display device such as an HMI (Human Machine Interface), and an IG switch via the input / output I / F.

[0037] The in-vehicle communication unit 23 is an input / output interface using a communication protocol such as CAN or Ethernet (registered trademark), and the control unit 20 communicates with in-vehicle devices such as the in-vehicle ECU 3 or other relay devices connected to the in-vehicle network 5 via the in-vehicle communication unit 23. A plurality of in-vehicle communication units 23 (three in this embodiment) are provided, and a communication line (segment) constituting the in-vehicle network 5 is connected to each of the in-vehicle communication units 23. By providing a plurality of in-vehicle communication units 23 in this manner, the in-vehicle network 5 is divided into a plurality of segments, and each in-vehicle ECU 3 is connected to each segment.

[0038] The in-vehicle ECU 3 includes a control unit 30, a storage unit 31, and an in-vehicle communication unit 32, similar to the in-vehicle device 2. The storage unit 31 is configured with a volatile memory element such as a random access memory (RAM) or a non-volatile memory element such as a read only memory (ROM), an electrically erasable programmable ROM (EEPROM), or a flash memory, and stores a program or data of the in-vehicle ECU 3. The program or data is to be updated by an update program transmitted from an external server S1 and relayed by the in-vehicle device 2. The in-vehicle communication unit 32 of the in-vehicle ECU 3 is configured with, for example, a CAN transceiver or an Ethernet PHY unit, similar to the in-vehicle device 2, and communicates with the in-vehicle device 2 via the in-vehicle communication unit 32.

[0039] The in-vehicle ECU 3 includes a single-face ECU 301 and a dual-face ECU 302, and the single-face ECU 301 and the dual-face ECU 302 have different types of storage areas in the storage unit 31. The storage unit 31 of the dual-face ECU 302 includes a first storage area 311 (first surface: A memory) and a second storage area 312 (second surface: B memory) as storage areas for storing an update program (a program executed when a function is exercised). The dual-face ECU 302 executes a program saved (stored) in either of the storage areas (the first storage area 311 or the second storage area 312) to execute the vehicle control process that the dual-face ECU 302 is responsible for. At this time, the storage area (the first storage area 311 or the second storage area 312) in which the program to be executed is stored corresponds to an operating surface (functional surface), and the other storage area corresponds to a non-operating surface. The in-vehicle ECU 3 may recognize which storage area is the operational surface (functional surface) by referring to state parameters or flag values, etc., stored in the storage unit.

[0040] The storage unit 31 of the single-face ECU 301 includes only a first storage area 311 (first surface: A memory) as a storage area for storing the update program. Furthermore, the single-face ECU 301 is classified into a single-face ECU 301 having a shared storage device 4 (shared memory) and a single-face ECU 301 not having the shared storage device 4. In the single-face ECU 301 having the shared storage device 4, the operation surface (functional surface) may be the storage area of ​​either the shared storage device 4 or the storage unit 31 (first storage area 311). The shared storage device 4 is communicably connected to each of the two or more single-face ECUs 301 (single-face ECUs 301 having the shared storage device 4) by a connection form and cable conforming to, for example, USB (Universal Serial Bus) or SPI (Serial Peripheral Interface).

[0041] The shared storage device 4 includes a RAM and has a communication function via USB, SPI, or the like. The shared storage device 4 may include an exclusive area that can be exclusively accessed by only one of the single ECUs 301 connected thereto (an area that can be accessed only by one single ECU 301 and an area that can be accessed only by the other single ECU 301), and a shared area that can be accessed by all of the single ECUs 301. The shared storage device 4 stores programs executed by each of the single ECUs 301 connected thereto, and therefore update programs from an in-vehicle device (OTA master) are saved (stored) in the shared storage device 4.

[0042] FIG. 3 is an explanatory diagram illustrating ECU management information (ECU management table). The in-vehicle device 2 periodically, cyclically, or steadily communicates with all in-vehicle ECUs 3 mounted on the vehicle C (own vehicle) and acquires information on these in-vehicle ECUs 3. For example, when the IG switch is turned on or off, or at a predetermined timing, the in-vehicle device 2 may request all in-vehicle ECUs 3 or a specific in-vehicle ECU 3 steadily mounted on the vehicle C to transmit configuration information of its own ECU. The in-vehicle device 2 acquires and aggregates the configuration information transmitted from each of the in-vehicle ECUs 3, and stores the aggregated configuration information as ECU management information (vehicle configuration information). Alternatively, the storage unit 21 of the in-vehicle device 2 may store the configuration information of all in-vehicle ECUs 3 mounted on the own vehicle (vehicle C) as ECU management information (vehicle configuration information) at the production stage of the vehicle C.

[0043] ECU management information (vehicle configuration information) regarding all the in-vehicle ECUs 3 mounted on the vehicle (vehicle C) may be stored in the storage unit 21, for example, in a table format (ECU management table). The ECU management table includes, as management items (fields), for example, ECU ID, connection bus number, function, classification, and software part number. The management item of ECU ID stores an identification number, such as a consecutive number, for uniquely identifying each of the in-vehicle ECUs 3 mounted on the vehicle C. The management item of connection bus number stores, when the in-vehicle device 2 functions as a relay device such as a CAN gateway, the number of the connection bus of the in-vehicle device 2 to which the in-vehicle ECU 3 is connected (device number of the in-vehicle communication unit 23), and the like.

[0044] The function management item stores the type of function (operation) that the in-vehicle ECU 3 is responsible for. The function (operation) includes, for example, function-limited driving control, charging control, minimum body control, body control, and other control. The function-limited driving control relates to control (evacuation driving control) when some functions in the vehicle C are stopped or limited to drive when the vehicle C is in an abnormal operation state. The charging control relates to control related to charging when a storage battery mounted on the vehicle C is charged when the vehicle C is in a stopped state (IG switch or power switch is in an off state). The minimum body control relates to control that is the minimum required control during the operation of the vehicle C in the control of various body actuators. The body control relates to control other than the above-mentioned minimum body control in the control of various body actuators, and relates to control that has a lower priority (ASIL: Automotive Safety Integrity Level) than the minimum body control in the operation of the vehicle C. The other controls are controls other than the above-mentioned function limited driving control, charging control, minimum body control, and body control, and relate to controls with a priority (ASIL) equal to or lower than that of the body control.

[0045] The classification management items store classifications (classifications) of the types of storage areas of the in-vehicle ECU 3 when the in-vehicle ECU 3 operates in response to the vehicle state. The types of storage areas include a type (two-sided ECU 302) having a first storage area 311 and a second storage area 312, and a type (single-sided ECU 301) having only the first storage area 311. Furthermore, the type (single-sided ECU 301) having only the first storage area 311 includes a type having a shared storage device 4 and a type not having the shared storage device 4.

[0046] The form of the storage area is determined based on the function (operation) performed by the in-vehicle ECU 3. The in-vehicle ECU 3 performing limited-function driving control or charging control is configured in a form having a first storage area 311 and a second storage area 312 (two-sided ECU 302). The in-vehicle ECU 3 performing minimum body control is configured in a form including a shared storage device 4 (single-sided ECU 301). The in-vehicle ECU 3 performing body control or other control is configured in a form not including a shared storage device 4 (single-sided ECU 301). In this way, depending on the function of the in-vehicle ECU 3 operating for each scene of the vehicle C, the in-vehicle ECU 3 is classified into the two-sided ECU 302, the single-sided ECU 301 including the shared storage device 4, and the single-sided ECU 301 not including the shared storage device 4.

[0047] FIG. 4 is an explanatory diagram illustrating an example of scene information (vehicle scene table). In the storage unit 21 of the in-vehicle device 2, scene information on the in-vehicle ECU 3 to which the update program is to be sent is stored, for example, in a table format (vehicle scene table) in accordance with the operation (function) corresponding to the vehicle state information during the production stage of the vehicle C. Furthermore, the control unit 20 of the in-vehicle device 2 may update the vehicle scene table by acquiring the scene information from the external server S1 and storing it in the storage unit 21. By acquiring the scene information from the external server S1 in this way, the vehicle scene table can be updated to the latest state in response to the provision of an update program by the external server S1.

[0048] The vehicle scene table includes, as management items, a scene (vehicle state), function-limited driving control, charging control, minimum body control, body control, and other control. The management item of the scene (vehicle state) stores each type of the scene (vehicle state). In this embodiment, the scene (vehicle state) includes a charging state, a running state, a maintenance state, a stopped state (without user request), and a stopped state (with user request). The items indicating each type of these scenes (vehicle states) are merely examples, and are not limited to these items, and may be further subdivided.

[0049] The charging state (when charging) is, for example, a state in which the vehicle C is stopped (IG switch or power switch is off) and the storage battery mounted on the vehicle C is being charged. The running state (when running) is, for example, a state in which the vehicle C is started (IG switch or power switch is on) and the vehicle speed is other than 0 km. The maintenance state (when maintenance is on) is, for example, a state in which the vehicle C is stopped (IG switch or power switch is off) and a diagnostic device or the like is connected to a service port such as a DLC (Data Link Connector) of the vehicle C. The stopped state (when stopped) is a state in which the vehicle C is stopped (IG switch or power switch is off) or started (IG switch or power switch is on) and, for example, the vehicle speed is 0 km, the handbrake is on, or the gear is set to park.

[0050] The stopped state (when stopped) is further subdivided according to the presence or absence of a user request, and is distinguished into a stopped state (with user request) and a stopped state (without user request). The stopped state (without user request) is a stopped state (when stopped) in which the user (operator of the vehicle C) has not requested (reprogramming) the update program (unauthorized state). The stopped state (with user request) is a stopped state (when stopped) in which the user (operator of the vehicle C) has requested (authorized state) the update program (reprogramming). The control unit 20 of the in-vehicle device 2 (OTA master) acquires communication data such as various messages via the in-vehicle network 5, and derives (acquires) vehicle state information (vehicle scene) indicating the state of the vehicle C (charging state, running state, maintenance state, stopped state, etc.) by performing a determination process or a classification process based on the type (message ID, etc.) and content (interpretation of payload) of the acquired communication data.

[0051] The management items of the function-limited driving control, the charging control, the minimum body control, the body control, and other control each store a rewrite mode corresponding to the scene (vehicle state) indicated by the vehicle state information. In this way, the vehicle scene table defines the mode of application of the update program to each of the in-vehicle ECUs 3 that perform each function according to the scene (vehicle state), so that the control unit 20 of the in-vehicle device 2 can efficiently identify the in-vehicle ECUs 3 to be updated.

[0052] When the scene (vehicle state) is a charging state (charging), the control unit 20 of the in-vehicle device 2 (OTA master) determines to rewrite the non-operating side (side B) of the in-vehicle ECU 3 (two-sided ECU 302) for function-limited driving control or charging control. Furthermore, the control unit 20 of the in-vehicle device 2 (OTA master) determines that there is no rewriting (not subject) to the in-vehicle ECU 3 (single-sided ECU 301 with the shared storage device 4) for minimum body control. Furthermore, the control unit 20 of the in-vehicle device 2 (OTA master) determines to rewrite the first storage area 311 (side A) of the in-vehicle ECU 3 (single-sided ECU 301 without the shared storage device 4) that is responsible for body control or other control. In this way, when the vehicle C is in a charging state (charging), by identifying the in-vehicle ECU 3 to be updated (update target ECU), it is possible to ensure that the vehicle can be driven at a minimum level even if the rewriting of the update program is canceled.

[0053] When the scene (vehicle state) is a driving state (driving), the control unit 20 of the in-vehicle device 2 (OTA master) determines to rewrite the non-operating side (side B) of the in-vehicle ECU 3 (two-sided ECU 302) for limited-function driving control or charging control. Furthermore, the control unit 20 of the in-vehicle device 2 (OTA master) determines that the in-vehicle ECU 3 for minimum body control (single-sided ECU 301 with the shared storage device 4) is not to be rewritten (is not to be rewritten). Furthermore, the control unit 20 of the in-vehicle device 2 (OTA master) determines that the in-vehicle ECU 3 (single-sided ECU 301 without the shared storage device 4) for body control or other control is not to be rewritten (is not to be rewritten). In this way, when the vehicle C is in a driving state (driving), by identifying the in-vehicle ECU 3 to be updated (the ECU to be updated), only the two-sided in-vehicle ECU 3 (the two-sided ECU 302) can be rewritten so as not to affect driving.

[0054] When the scene (vehicle state) is a maintenance state (during maintenance), the control unit 20 of the in-vehicle device 2 (OTA master) judges to rewrite the non-operating side (side B) of the in-vehicle ECU 3 (two-sided ECU 302) for limited-function driving control or charging control. Furthermore, the control unit 20 of the in-vehicle device 2 (OTA master) judges to rewrite the shared storage device 4 of the in-vehicle ECU 3 (single-sided ECU 301 with the shared storage device 4) for minimum body control. Furthermore, the control unit 20 of the in-vehicle device 2 (OTA master) judges to rewrite the first storage area 311 (side A) of the in-vehicle ECU 3 (single-sided ECU 301 without the shared storage device 4) that is responsible for body control or other control. In this way, when the vehicle C is in a maintenance state (during maintenance), by identifying the in-vehicle ECU 3 to be updated (the update program is applied) in a state where safety is ensured in a garage or the like, all the in-vehicle ECUs 3 can be rewritten.

[0055] When the scene (vehicle state) is a stopped state (no user request), the control unit 20 of the in-vehicle device 2 (OTA master) determines to rewrite the non-operating side (side B) of the in-vehicle ECU 3 (two-sided ECU 302) for limited-function driving control or charging control. Furthermore, the control unit 20 of the in-vehicle device 2 (OTA master) determines that the in-vehicle ECU 3 for minimum body control (single-sided ECU 301 with a shared storage device 4) is not to be rewritten (is not to be rewritten). Furthermore, the control unit 20 of the in-vehicle device 2 (OTA master) determines that the in-vehicle ECU 3 (single-sided ECU 301 without a shared storage device 4) for body control or other control is not to be rewritten (is not to be rewritten). In this way, when the vehicle C is stopped (no user request), by identifying the in-vehicle ECU 3 to be updated (the ECU to be updated), only the two-sided in-vehicle ECU 3 (the two-sided ECU 302) can be rewritten so as not to affect the stop control.

[0056] When the scene (vehicle state) is a stopped state (user request), the control unit 20 of the in-vehicle device 2 (OTA master) determines to rewrite the non-operating side (side B) of the in-vehicle ECU 3 (two-sided ECU 302) for limited-function driving control or charging control. Furthermore, the control unit 20 of the in-vehicle device 2 (OTA master) determines that the in-vehicle ECU 3 for minimum body control (single-sided ECU 301 with a shared storage device 4) is not to be rewritten (is not subject to rewriting). Furthermore, the control unit 20 of the in-vehicle device 2 (OTA master) determines to rewrite the first memory area 311 (side A) of the in-vehicle ECU 3 (single-sided ECU 301 without a shared storage device 4) responsible for body control or other control. In this way, by identifying the in-vehicle ECU 3 to be updated (update target ECU) when the vehicle C is stopped (user request), It is possible to guarantee that the vehicle will be able to drive at a minimum level even if the update program rewrite is canceled.

[0057] 5 is a flowchart illustrating the processing of the control unit 20 of the in-vehicle device 2. When the charge amount of the power storage device of the in-vehicle device 2 is equal to or greater than a predetermined value even when the vehicle C is in a running state (IG switch is on) or stopped state (IG switch is off), the control unit 20 of the in-vehicle device 2 constantly communicates with an external server S1 (program providing device) via the external communication device 1 and performs the following processing.

[0058] The control unit 20 of the in-vehicle device 2 determines whether or not it is necessary to acquire an update program (S101). The control unit 20 of the in-vehicle device 2 determines whether or not it is necessary to acquire an update program based on whether or not an update program has been transmitted from an external server S1 (OTA server) through communication with the external server S1. The control unit 20 of the in-vehicle device 2 stores the acquired (received) update program in the storage unit 21. Alternatively, the control unit 20 of the in-vehicle device 2 periodically or constantly communicates with the external server S1 (OTA server) and determines whether or not it is necessary to acquire an update program based on whether or not, for example, campaign information (OTA target ECU rewrite request) has been notified from the external server S1. If the campaign information has been notified, the control unit 20 of the in-vehicle device 2 determines that it is necessary to acquire an update program. If the campaign information has not been notified, the control unit 20 of the in-vehicle device 2 determines that it is not necessary to acquire an update program.

[0059] When it is determined that the update program does not need to be acquired (S101: NO), the control unit 20 of the vehicle-mounted device 2 performs a loop process to execute the process from S101 again. The control unit 20 of the vehicle-mounted device 2 thus continues to execute the relay process while continuing the process of waiting for campaign information from the external server S1.

[0060] When it is determined that the update program needs to be acquired (S101: YES), the control unit 20 of the in-vehicle device 2 acquires vehicle state information (S102). When it is determined that the update program needs to be acquired, the control unit 20 of the in-vehicle device 2 acquires and stores the update program and acquires vehicle state information. The control unit 20 of the in-vehicle device 2 may derive (acquire) vehicle state information (vehicle scene) indicating the state of the vehicle C (charging state, running state, maintenance state, parked state, etc.) based on the communication data acquired via the in-vehicle network 5.

[0061] The control unit 20 of the in-vehicle device 2 identifies the in-vehicle ECU 3 to be updated (S103). The control unit 20 of the in-vehicle device 2 recognizes the in-vehicle ECU 3 to be updated based on the campaign information acquired from the external server S1. Furthermore, the control unit 20 of the in-vehicle device 2 identifies the in-vehicle ECU 3 (OTA target ECU) for which the update process (reproduction process) is possible, by referring to the ECU management table and the vehicle scene table stored in the storage unit 21, based on the acquired vehicle state information (vehicle scene). As described above, in the vehicle scene table, the in-vehicle ECU 3 to be rewritten by the update program is defined in the vehicle state information (vehicle scene) according to the function (operation) of the in-vehicle ECU 3. The form of the storage area of ​​each in-vehicle ECU 3 according to the function (operation) is defined in the ECU management table.

[0062] The control unit 20 of the in-vehicle device 2 transmits the update program (S104). The control unit 20 of the in-vehicle device 2 transmits the update program to each of the in-vehicle ECUs 3 (OTA target ECUs) identified according to the vehicle state information (vehicle scene).

[0063] The control unit 20 of the in-vehicle device 2 determines whether or not a cancellation request has been received (S105). While transmitting the update program to the in-vehicle ECU 3 (OTA target ECU), the control unit 20 of the in-vehicle device 2 determines whether or not a signal (cancellation request signal) for interrupting the update process (reprogramming process) has been received, such as a cancellation request from any of the in-vehicle ECUs 3, a cancellation request by an operation of a user (operator of the vehicle C), or a cancellation request from the external server S1.

[0064] When it is determined that there is a cancel request (S105: YES), the control unit 20 of the in-vehicle device 2 transmits a cancel instruction (S1051). When it is determined that there is a cancel request, the control unit 20 of the in-vehicle device 2 transmits a cancel instruction to each of the identified in-vehicle ECUs 3 (OTA target ECUs). By transmitting the cancel instruction, the control unit 20 of the in-vehicle device 2 may cause each of the identified in-vehicle ECUs 3 (OTA target ECUs) to execute a rollback process.

[0065] When it is determined that there is no cancellation request (S105: NO), the control unit 20 of the in-vehicle device 2 determines whether the reprogramming is complete (S106). When it is determined that there is no cancellation request, the control unit 20 of the in-vehicle device 2 determines whether the processing required for the reprogramming in the in-vehicle ECUs 3, such as the transmission of update programs to all identified in-vehicle ECUs 3 (OTA target ECUs), is complete. When it is determined that the reprogramming is not complete (S106: NO), the control unit 20 of the in-vehicle device 2 performs loop processing to execute the processing from S104 again.

[0066] When it is determined that the reprogramming is completed (S106: YES), the control unit 20 of the in-vehicle device 2 transmits an activation request to the in-vehicle ECUs 3 to be updated (S107). When it is determined that the reprogramming is completed, the control unit 20 of the in-vehicle device 2 transmits an activation request to all of the identified in-vehicle ECUs 3 (OTA target ECUs) that are the in-vehicle ECUs to be updated.

[0067] The control unit 30 of the in-vehicle ECU 3 executes vehicle control processing (T101). When the vehicle C is started or stopped, each of the in-vehicle ECUs 3 determines (recognizes) a functional surface (operational surface) in the storage unit 31 of the in-vehicle ECU 3 in which a program to be executed is stored, and starts up by executing the program stored in the functional surface (operational surface), and starts the vehicle control processing that each of the in-vehicle ECUs 3 is responsible for.

[0068] The control unit 30 of the in-vehicle ECU 3 determines whether or not an update program has been received (T102). As described above, the in-vehicle device 2 (OTA master) identifies one or more in-vehicle ECUs 3 (update target ECUs) to which the update program is to be sent, according to vehicle state information (scene) indicating the current state of the vehicle C. The control unit 30 of the in-vehicle ECU 3 determines whether or not an update program has been received from the in-vehicle device 2 (OTA master). If it is determined that the update program has not been received (T102: NO), the control unit 30 of the in-vehicle ECU 3 performs loop processing to execute the processing from T101 again.

[0069] When it is determined that the update program has been received (T102: YES), the control unit 30 of the in-vehicle ECU 3 stores the update program (T103). When it is determined that the update program has been received, the control unit 30 of the in-vehicle ECU 3 stores the update program acquired from the in-vehicle device 2 in the first storage area 311, the second storage area 312, or the shared storage device 4 according to the form of the storage area of ​​the in-vehicle ECU 3 itself (the in-vehicle ECU 3). That is, the single-face ECU 301 stores the update program acquired from the in-vehicle device 2 in the first storage area 311. When the inactive surface of the dual-face ECU 302 is the second storage area 312 (second surface: B memory), the dual-face ECU 302 stores the update program acquired from the in-vehicle device 2 in the second storage area 312 (second surface: B memory). The single-face ECU 301 provided with the shared storage device 4 stores the update program acquired from the in-vehicle device 2 in the shared storage device 4.

[0070] The control unit 30 of the in-vehicle ECU 3 determines whether or not a cancel instruction has been received (T104). The control unit 30 of the in-vehicle ECU 3 determines whether or not a cancel instruction has been received from the in-vehicle device 2 (OTA master). When it is determined that a cancel instruction has been received (T104: YES), the control unit 30 of the in-vehicle ECU 3 performs a loop process to execute the process from T101 again. When the control unit 30 of the in-vehicle ECU 3 receives a cancel instruction, the control unit 30 may perform a rollback process in response to the cancel instruction. By performing the rollback process, the control unit 30 of the in-vehicle ECU 3 may discard the update program transmitted from the in-vehicle device 2 (OTA master) and execute a program (previous version program) that was used until immediately before the update process was performed, thereby resuming the vehicle control process performed by each of the in-vehicle ECUs 3.

[0071] When it is determined that a cancel instruction has not been received (T104: NO), the control unit 30 of the in-vehicle ECU 3 determines whether or not the reprogramming is completed (T105). When it is determined that a cancel instruction has not been received from the in-vehicle device 2 (OTA master), the control unit 30 of the in-vehicle ECU 3 determines whether or not the reprogramming to the acquired update program has been completed. When determining the completion of the reprogramming to the update program, the control unit 30 of the in-vehicle ECU 3 may, for example, perform a self-diagnosis process using the update program.

[0072] When it is determined that the reprogramming is not completed (T105: NO), the control unit 30 of the in-vehicle ECU 3 performs a loop process to execute the process from T101 again. Alternatively, when it is determined that the reprogramming is not completed, the control unit 30 of the in-vehicle ECU 3 may acquire (reacquire) the update program from the in-vehicle device 2 (OTA master) again.

[0073] When it is determined that the rewriting is completed (T105: YES), the control unit 30 of the in-vehicle ECU 3 receives an activation request (T106). When it is determined that the rewriting to the acquired update program is completed, the control unit 30 of the in-vehicle ECU 3 receives an activation request from the in-vehicle device 2 (OTA master). In response to the received (acquired) activation request, the control unit 30 of the in-vehicle ECU 3 performs a reset process or a restart process to execute the update program whose rewriting has been completed. At this time, the dual-faceted ECU 302 may perform the restart process or the like using a storage area in which the update program is stored (for example, the second storage area 312 (second surface: B memory)) as an operating surface (functional surface).

[0074] As shown in the above flow, the in-vehicle device 2 and the in-vehicle ECU 3 communicate with each other and perform a series of processes related to reprogramming, including transmission and reception of update programs. That is, the control unit 20 of the in-vehicle device 2 performs a series of processes related to the reprogramming by executing a scene determination module included in a control program stored in the storage unit 21 and, if necessary, a rollback control module. Below, each mode of reprogramming corresponding to each scene will be described.

[0075] FIG. 6 is an explanatory diagram illustrating one mode of rewriting during charging, etc. When the vehicle state information (vehicle scene) is in a charging state (when charging) or a stopped state (when a user request is made), the in-vehicle update system S performs the rewriting mode illustrated in FIG. 6. When the vehicle state information (vehicle scene) is in a charging state (when charging) or a stopped state (when a user request is made), the two-sided ECU 302, which is the in-vehicle ECU 3 for function-limited driving control and charging control, sets the first storage area 311 (first surface: A memory) as the operating surface to be in operation, and sets the second storage area 312 (second surface: B memory) as the non-operating surface to be in reprogress (when an update program is being written). The one-sided ECU 301, which is equipped with the shared storage device 4, which is the in-vehicle ECU 3 for minimum body control, sets the shared storage device 4 (shared memory) to be in operation, and sets the first storage area 311 (first surface: A memory) to be in reprogress (when an update program is being written). The single-surface ECU 301 not including the shared storage device 4, which is the in-vehicle ECU 3 responsible for body control or other controls, is in the process of reprogramming the first storage area 311 (first surface: A memory) (writing an update program).

[0076] FIG. 7 is an explanatory diagram illustrating one mode of rewriting during driving, etc. When the vehicle state information (vehicle scene) is a driving state (driving) or a stopped state (no user request), the in-vehicle update system S performs the rewriting mode illustrated in FIG. 7. The two-sided ECU 302, which is the in-vehicle ECU 3 for limited-function driving control and charging control, has the first storage area 311 (first side: A memory) as the operating side in operation, and the second storage area 312 (second side: B memory) as the non-operating side in repro (writing an update program). The one-sided ECU 301 with the shared storage device 4, which is the in-vehicle ECU 3 for minimum body control, has the shared storage device 4 (shared memory) in operation, and the first storage area 311 (first side: A memory) in operation. The single-surface ECU 301 not including the shared storage device 4, which is the in-vehicle ECU 3 responsible for body control or other controls, operates the first storage area 311 (first surface: A memory).

[0077] Fig. 8 is an explanatory diagram illustrating one aspect of rewriting during maintenance, etc. When the vehicle state information (vehicle scene) is in a maintenance state (during maintenance), the in-vehicle update system S has a two-sided ECU 302, which is an in-vehicle ECU 3 for function-limited driving control and charging control, which is in the rewriting aspect illustrated in Fig. 8, with the first storage area 311 (first surface: A memory) as the operating surface in operation, and the second storage area 312 (second surface: B memory) as the non-operating surface in re-progress (update program being written). The one-sided ECU 301, which is an in-vehicle ECU 3 for minimum body control and includes a shared storage device 4, has the shared storage device 4 (shared memory) in re-progress (update program being written), and the first storage area 311 (first surface: A memory) in re-progress (update program being written). The single-surface ECU 301 not including the shared storage device 4, which is the in-vehicle ECU 3 responsible for body control or other controls, is in the process of reprogramming the first storage area 311 (first surface: A memory) (writing an update program).

[0078] The embodiments disclosed herein are illustrative in all respects and should not be considered as limiting. The scope of the present invention is defined by the claims, not by the above meaning, and is intended to include all modifications within the scope and meaning equivalent to the claims.

[0079] The claims may be combined with each other regardless of the form of reference. The claims may contain multiple dependent claims depending on multiple claims. Multiple dependent claims may be contained depending on multiple dependent claims. If multiple dependent claims are not contained depending on a multiple dependent claim, this does not limit the number of dependent claims depending on a multiple dependent claim. [Explanation of symbols]

[0080] C Vehicle S In-vehicle update system S1 External server (program providing device) 1. External communication device 11 Antenna 2. In-vehicle device (OTA master) 20 Control section 21 Memory section P Control program (program product) M Recording medium 22 Input / Output Interface 23 In-vehicle communication unit 3 In-vehicle ECU 30 Control section 31 Storage section 311 First memory area (first side: A memory) 312 Second memory area (Second side: B memory) 32 In-vehicle communication unit 301 Single-sided ECU 302 2-sided ECU 4 Shared storage 5. In-vehicle network

Claims

1. An in-vehicle device that acquires an update program transmitted from an external server outside the vehicle and performs a process for updating a program of an in-vehicle ECU mounted in the vehicle, A control unit that performs processing related to the update program, the in-vehicle ECU includes a dual-purpose ECU having a first storage area and a second storage area as areas for storing the update program, and a single-purpose ECU having only the first storage area; The control unit is Acquire vehicle status information indicating a status of the vehicle; Identifying one or more in-vehicle ECUs to which the update program is to be transmitted according to the acquired vehicle state information; The update program is transmitted to the one or more specified vehicle-mounted ECUs. In-vehicle device.

2. The vehicle is equipped with a shared storage device that is shared by the plurality of single-sided ECUs, When the vehicle state information indicates a maintenance state, the control unit transmits the update program to the shared storage device connected to the one-sided ECU identified as a transmission destination. The in-vehicle device according to claim 1 .

3. The state of the vehicle includes a charging state, a running state, a maintenance state, and a stopped state, The control unit determines which state the vehicle is in based on the vehicle state information. The vehicle-mounted device according to claim 2 .

4. Each of the in-vehicle ECUs is classified into the dual-sided ECU, the single-sided ECU, or the ECU equipped with the shared storage device based on an operation corresponding to a state of the vehicle; The storage unit in which the update program acquired from the external server is stored stores ECU management information indicating the classification of each of the vehicle-mounted ECUs. The vehicle-mounted device according to claim 3.

5. The storage unit stores scene information that defines an association between the vehicle state information and an in-vehicle ECU that is a destination of the update program, The control unit refers to the ECU management information and the scene information based on the vehicle state information, and identifies one or more in-vehicle ECUs to which the update program is to be transmitted. The vehicle-mounted device according to claim 4.

6. An update processing method for causing a computer to execute a process for acquiring an update program transmitted from an external server outside a vehicle and updating a program of an on-board ECU mounted in a vehicle, comprising: the in-vehicle ECU includes a dual-purpose ECU having a first storage area and a second storage area as areas for storing the update program, and a single-purpose ECU having only the first storage area; The computer Acquire vehicle status information indicating a status of the vehicle; Identifying one or more in-vehicle ECUs to which the update program is to be transmitted according to the acquired vehicle state information; The update program is transmitted to the one or more specified vehicle-mounted ECUs. The update processing method that causes the processing to be performed.

7. A plurality of on-board ECUs mounted on a vehicle; an in-vehicle device that acquires an update program transmitted from an external server outside the vehicle and performs processing for updating the program of the in-vehicle ECU; An in-vehicle update system comprising: the in-vehicle device includes a control unit that performs processing related to the update program, the in-vehicle ECU includes a dual-purpose ECU having a first storage area and a second storage area as areas for storing the update program, and a single-purpose ECU having only the first storage area; The control unit of the in-vehicle device Acquire vehicle status information indicating a status of the vehicle; Identifying one or more in-vehicle ECUs to which the update program is to be transmitted according to the acquired vehicle state information; The update program is transmitted to the one or more specified vehicle-mounted ECUs. In-vehicle update system.

Images