In-vehicle device, program, and information processing method

Abstract

This in-vehicle device comprises a control unit that acquires an additional program transmitted from an external server outside the vehicle and performs processing for applying the additional program to an in-vehicle ECU mounted on the vehicle. The control unit acquires information about a function allocation destination ECU identified according to a determination result related to a necessary resource condition and a function allocation condition from among a plurality of in-vehicle ECUs mounted on the vehicle, and relays the additional program acquired from the external server to the identified function allocation destination ECU according to the acquired information.

Description

In-vehicle device, program, and information processing method

[0001] This application claims priority to Japanese Patent Application No. 2023-210516 filed on December 13, 2023, and incorporates by reference all of the contents of that application.

[0002] A vehicle is equipped with an ECU (Electronic Control Unit) for controlling on-board devices such as drive control systems (e.g., engine control) and body systems (e.g., air conditioning control). The ECU includes an arithmetic processing unit such as an MPU, a rewritable nonvolatile storage unit such as an EEPROM, and a communication unit for communicating with other ECUs, and controls the on-board devices by reading and executing control programs stored in the storage unit. The vehicle is also equipped with a communication device with wireless communication capabilities, and can communicate with a program provider connected to a network outside the vehicle via the communication device, download (receive) a control program for the ECU from the program provider, and update the control program for the ECU (see, for example, Patent Document 1).

[0003] Japanese Patent Application Laid-Open No. 2017-97851

[0004] An in-vehicle device according to one aspect of the present disclosure is an in-vehicle device that includes a control unit that acquires an additional program transmitted from an external server outside the vehicle and performs processing to apply the additional program to an in-vehicle ECU installed in the vehicle, wherein the control unit acquires information regarding a function placement destination ECU identified among a plurality of in-vehicle ECUs installed in the vehicle based on determination results regarding required resource conditions and function placement conditions, and relays the additional program acquired from the external server to the identified function placement destination ECU based on the acquired information.

[0005] 1 is a schematic diagram illustrating the configuration of an in-vehicle system including an in-vehicle device according to a first embodiment; FIG. 2 is a block diagram illustrating the physical configuration of the in-vehicle device; FIG. 3 is a flowchart illustrating the processing (main) of a control unit of the in-vehicle device; FIG. 4 is a flowchart illustrating the processing (function placement determination) of a control unit of the in-vehicle device; FIG. 5 is a flowchart illustrating the processing (function placement resource condition determination) of a control unit of the in-vehicle device; FIG. 6 is a diagram illustrating the processing (function placement destination ECU determination) of a control unit of the in-vehicle device; FIG. 7 is an explanatory diagram illustrating items related to a system evaluation value (system criteria information, weighting coefficient, etc.); FIG. 8 is an explanatory diagram illustrating items related to resources required for a target function; FIG. 9 is an explanatory diagram illustrating items related to resource information of candidate ECUs; FIG. 10 is an explanatory diagram illustrating items related to a target function feasibility evaluation value; FIG. 11 is an explanatory diagram illustrating items related to evaluation signal access information; FIG. 12 is an explanatory diagram illustrating items related to evaluation function placement information; FIG. 13 is an explanatory diagram illustrating items related to in-vehicle network configuration information; FIG. 14 is a flowchart illustrating the processing of a control unit of an in-vehicle device according to a second embodiment (external server performs simulation). MODES FOR CARRYING OUT THE INVENTION

[0006] [Problem that the present disclosure aims to solve] The communication device (repeater) of Patent Document 1 does not take into consideration how to efficiently identify an ECU installed in a vehicle when applying an additional program obtained from an external server to that ECU.

[0007] An object of the present disclosure is to provide an in-vehicle device or the like that can efficiently identify an ECU mounted on a vehicle when applying an additional program acquired from an external server to the ECU.

[0008] [Effects of the Present Disclosure] According to one aspect of the present disclosure, it is possible to provide an in-vehicle device or the like that can efficiently identify an ECU installed in a vehicle when applying an additional program acquired from an external server to the ECU.

[0009] [Description of 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 combined in any manner.

[0010] (1) An in-vehicle device according to one aspect of the present disclosure is an in-vehicle device including a control unit that acquires an additional program transmitted from an external server outside the vehicle and performs processing to apply the additional program to an in-vehicle ECU mounted on the vehicle, wherein the control unit acquires information regarding a function placement ECU identified based on a determination result regarding necessary resource conditions and function placement conditions among a plurality of in-vehicle ECUs mounted on the vehicle, and relays the additional program acquired from the external server to the function placement ECU identified based on the acquired information.

[0011] In this aspect, an in-vehicle device mounted on a vehicle is communicatively connected to an external server, such as an over-the-air (OTA) server, located outside the vehicle via an external communication device having wireless capabilities. The external server stores (stores) add-on programs or update programs to be applied to various in-vehicle ECUs mounted on the vehicle, and adds software functions to the vehicle by transmitting the add-on programs to the vehicle (in-vehicle device). A control unit of the in-vehicle device acquires necessary resource conditions and function layout conditions, which are conditions that must be met for applying the add-on program, when applying the add-on program acquired from the external server to one of multiple in-vehicle ECUs mounted on the vehicle. The control unit of the in-vehicle device may acquire the necessary resource conditions and function layout conditions from the external server. The control unit of the in-vehicle device identifies a function-layout ECU to which the add-on program should be applied based on the necessary resource conditions and function layout conditions acquired from the external server. The identified function-layout ECU corresponds to the in-vehicle ECU where the software function of the add-on program is to be laid out (the in-vehicle ECU that is the function-layout destination). Alternatively, the control unit of the in-vehicle device may identify the function-location destination ECU (the in-vehicle ECU where the function is to be located) by obtaining information about the ECU identified based on the determination results of the required resource conditions and the functional location conditions from an external server. When determining whether the required resource conditions and the functional location conditions required for executing the additional program are met or not, the control unit of the in-vehicle device may perform not only a simulation of each in-vehicle ECU alone but also a communication simulation over an in-vehicle network installed in the vehicle. The control unit of the in-vehicle device relays the additional program obtained from the external server to the identified function-location destination ECU based on the required resource conditions and the functional location conditions required for executing the additional program. This allows for efficient determination of a suitable location for the software function of the additional program when transmitting the additional program from the external server (over-the-air).By optimally allocating software functions, it is possible to appropriately secure a margin of hardware resources (mainly resources determined by required resource conditions) in each of the multiple onboard ECUs installed in a vehicle, thereby ensuring room for adding additional software functions. Furthermore, by optimally allocating software functions, it is possible to prevent a decrease in responsiveness, including existing functions, in each of the multiple onboard ECUs. It is also possible to reduce the risk of resource shortages occurring in any of the onboard ECUs due to localized concentration of functions.

[0012] (2) In an in-vehicle device according to one aspect of the present disclosure, the determination regarding the required resource conditions and the function placement conditions is performed by the external server, and the control unit outputs vehicle information including information regarding the resources of each of the multiple in-vehicle ECUs to the external server, and obtains from the external server information regarding the ECU to which the function is to be placed, which is identified by the external server based on the vehicle information and the required resource conditions and the function placement conditions in the additional program.

[0013] In this aspect, the determination of the required resource conditions and the functional layout conditions is performed by an external server, and the control unit of the in-vehicle device outputs vehicle information to the external server, including information about the resources of each of the multiple in-vehicle ECUs, which is information necessary for making the determination. The information about the resources of each of the multiple in-vehicle ECUs includes, for example, the CPU model, CPU operating frequency, memory model, memory storage capacity and available memory space, the type of program being executed (software part number, software function), the type of operating system (OS) implemented, the presence or absence of a virtual environment (VM), and the physical layer protocol of the implemented communication unit. Furthermore, the control unit of the in-vehicle device may also output information about the connection topology of the in-vehicle ECUs in the in-vehicle network (network topology information) as vehicle information to the external server. The external server acquires the vehicle information transmitted from the in-vehicle device and performs a simulation of each in-vehicle ECU and a communication simulation over the in-vehicle network based on the vehicle information and the required resource conditions and functional layout conditions for the additional program. Based on the simulation results, the external server identifies a destination ECU that satisfies the required resource conditions and the functional layout conditions, and transmits information about the destination ECU to the in-vehicle device. The control unit of the in-vehicle device transmits (relays) an additional program to the destination ECU based on the information about the destination ECU obtained from the external server. In this way, by using an external server such as a cloud server to perform the simulation-related process for determining whether the required resource conditions and the functional layout conditions are met, the computational load on the control unit of the in-vehicle device can be reduced, and the hardware resources required by the control unit can be prevented from becoming excessively high.

[0014] (3) In an in-vehicle device according to one aspect of the present disclosure, the control unit acquires from the external server the necessary resource conditions and the functional layout conditions required in the in-vehicle ECU or the vehicle to execute the additional program, extracts one or more of the in-vehicle ECUs that satisfy the necessary resource conditions as candidate ECUs, and identifies, from the extracted candidate ECUs, the candidate ECU that satisfies the functional layout conditions as the ECU to which the function is to be laid out.

[0015] In this aspect, when the control unit of the in-vehicle device acquires the additional program from the external server, it also acquires information (condition information) regarding the necessary resource conditions and functional layout conditions required in the in-vehicle ECU or the vehicle to execute the additional program. The control unit of the in-vehicle device first uses the acquired necessary resource conditions, which are information mainly regarding hardware resources in the in-vehicle ECU, to extract in-vehicle ECUs that satisfy the necessary resource conditions as candidate ECUs. The control unit of the in-vehicle device may determine whether the necessary resource conditions are met for all in-vehicle ECUs installed in the vehicle, extract one or more in-vehicle ECUs that satisfy the necessary resource conditions as candidate ECUs, and generate a primary placement candidate list consisting of the extracted candidate ECUs. The primary placement candidate list may be stored in the storage unit of the in-vehicle device in a list format in which the candidate ECUs are listed in the order in which they are determined to satisfy the necessary resource conditions. The control unit of the in-vehicle device uses a primary list of candidate placement ECUs, which lists one or more candidate ECUs, to sequentially determine whether each candidate ECU satisfies the functional placement conditions, and identifies a candidate ECU determined to satisfy the functional placement conditions (an in-vehicle ECU that satisfies the required resource conditions) as the ECU to which the function is to be placed. In this way, by first extracting candidate ECUs based on the required resource conditions, which define the conditions related to the hardware resources required by the in-vehicle ECU that executes the additional program, the in-vehicle ECUs to be subjected to the functional placement conditions can be narrowed down. This reduces the number of in-vehicle ECUs to be subjected to the functional placement conditions, which requires a simulation that involves a relatively high computational load. Therefore, when determining the functional placement conditions, the number of in-vehicle ECUs to be subjected to the functional placement conditions can be reduced, thereby efficiently identifying the in-vehicle ECU to which the additional program is to be applied.

[0016] (4) In the in-vehicle device according to one aspect of the present disclosure, the necessary resource conditions include at least one of a storage capacity, a CPU type, and an operating frequency of the in-vehicle ECU.

[0017] In this aspect, the necessary resource conditions required for the vehicle ECU to execute the additional program include at least one of the vehicle ECU's storage capacity, CPU type, and operating frequency. In other words, the necessary resource conditions mainly correspond to conditions related to the hardware resources of the vehicle ECU. The necessary resource conditions are not limited to the hardware resources themselves, such as the vehicle ECU's CPU or memory. The necessary resource conditions may also include, for example, the number of initialization steps, the number of periodic execution steps, or the allowable control delay time, which are calculated in combination with the vehicle ECU's CPU operating clock when the vehicle ECU executes the additional program, and the maximum allowable response time from sensor signal generation (receiving signals from various sensors) to actuator output (outputting control signals to vehicle loads controlled by the vehicle ECU). In this way, by defining necessary resource conditions corresponding to the required hardware resource requirements for the ECU to which the additional program is applied (i.e., where software function allocation is performed), it is possible to narrow down the vehicle ECUs (candidate ECUs) to be evaluated for the function allocation requirements, thereby reducing the computational load required for the function allocation requirements.

[0018] (5) In an in-vehicle device according to one aspect of the present disclosure, the functional layout conditions include functional layout necessary conditions and functional layout sufficient conditions that are more restrictive than the functional layout necessary conditions, and the control unit determines whether any of the extracted candidate ECUs meets the functional layout sufficient conditions. If a candidate ECU that meets the functional layout sufficient conditions is present, the control unit identifies the candidate ECU that meets the functional layout sufficient conditions as the ECU to which the functional layout is to be performed. If no candidate ECU meets the functional layout sufficient conditions, the control unit determines whether any of the candidate ECUs meets the functional layout necessary conditions.

[0019] In this aspect, the functional layout conditions include functional layout necessary conditions and functional layout sufficient conditions that are more restrictive than the functional layout necessary conditions. That is, the functional layout conditions include two-level condition values ​​for each of a plurality of condition items (layout condition items): functional layout necessary conditions and functional layout sufficient conditions. The functional layout necessary conditions and functional layout sufficient conditions are equivalent to necessary conditions and sufficient conditions in logical operations, for example. When shown in a Venn diagram, the range of the functional layout sufficient conditions may fall within the range defined by the functional layout necessary conditions. The control unit of the in-vehicle device first determines, for each of one or more extracted candidate ECUs, whether the candidate ECU satisfies the functional layout sufficient conditions, which are more conditionally restrictive. If the control unit of the in-vehicle device determines that the candidate ECU does not satisfy the functional layout sufficient conditions, the control unit of the in-vehicle device then determines whether the candidate ECU satisfies functional layout necessary conditions that are more conditionally relaxed than the functional layout sufficient conditions. In this way, if a candidate ECU that satisfies the functional placement sufficient condition exists, the control unit of the in-vehicle device identifies the candidate ECU that satisfies the functional placement sufficient condition as the ECU to which the function is to be placed, and if no candidate ECU that satisfies the functional placement sufficient condition exists, the control unit of the in-vehicle device determines whether a candidate ECU that satisfies the functional placement necessary condition exists. In this way, by performing a two-stage determination based on the functional placement necessary condition and the functional placement sufficient condition, the ECU to which the function is to be placed can be efficiently identified.

[0020] (6) In an in-vehicle device according to one aspect of the present disclosure, when there are multiple extracted candidate ECUs, the control unit sequentially determines whether the functional layout sufficient condition is met for each of the multiple candidate ECUs, and if it determines that the functional layout sufficient condition is met for any of the candidate ECUs, it interrupts the determination process for the functional layout sufficient condition without performing the determination process for any undetermined candidate ECUs that are ranked lower than any of the candidate ECUs.

[0021] In this aspect, the control unit of the in-vehicle device uses a primary list of candidate placement ECUs, in which multiple candidate ECUs are listed in the extracted order, to sequentially determine whether the candidate ECUs included in the primary list of candidate placement ECUs satisfy the functional placement sufficient condition. When the control unit of the in-vehicle device determines that any candidate ECU satisfies the functional placement sufficient condition, the control unit suspends the process of determining whether the functional placement sufficient condition is met without performing the determination process on any undetermined candidate ECUs that are ranked lower than the candidate ECU. In other words, the control unit of the in-vehicle device sequentially determines whether the functional placement sufficient condition is met for each candidate ECU in the order in which the candidate ECUs are listed in the extracted order, and, when the control unit determines that any candidate ECU satisfies the functional placement sufficient condition, identifies the candidate ECU as the ECU where the function is to be placed. The control unit of the in-vehicle device then suspends (ends) the process of determining whether the functional placement sufficient conditions are met for any undetermined candidate ECUs that are ranked lower than the identified functional placement ECU (candidate ECU that satisfies the functional placement sufficient conditions), i.e., any candidate ECUs that are listed lower than the identified functional placement ECU in the primary candidate list. This reduces the processing load associated with determining the functional placement conditions, which requires simulation and involves a relatively high computational load, reduces the processing time required to identify the functional placement ECU, and prevents an increase in the computation time required by the control unit of the in-vehicle device.

[0022] (7) In an in-vehicle device according to one aspect of the present disclosure, the functional placement conditions include a plurality of placement condition items, and the control unit extracts candidate ECUs that satisfy the functional placement requirements as second candidate ECUs, calculates the fulfillment rate of each of the placement condition items in each of the second candidate ECUs, and identifies the ECU to which the function is to be placed based on the fulfillment rate in each of the second candidate ECUs.

[0023] In this aspect, if there is no candidate ECU that satisfies the functional placement sufficient condition, the control unit of the in-vehicle device identifies a functional placement ECU from among candidate ECUs that satisfy functional placement necessary conditions that are more conditionally relaxed than the functional placement sufficient condition. In this case, the control unit of the in-vehicle device may extract candidate ECUs that satisfy the functional placement necessary condition as second candidate ECUs and generate a secondary placement candidate list consisting of one or more extracted second candidate ECUs. The secondary placement candidate list may be stored in the storage unit of the in-vehicle device in a list format in which the second candidate ECUs are listed in the order in which they are determined to satisfy the functional placement necessary condition. The control unit of the in-vehicle device calculates a fulfillment rate for each of the plurality of placement condition items included in the functional placement condition for each second candidate ECU listed in the secondary placement candidate list. The fulfillment rate may be calculated as follows: "Fulfillment rate = 1 - {(Evaluation value - Sufficient condition value) / (Necessary condition value - Sufficient condition value)}" using an evaluation value (evaluation value for each placement condition item) derived based on a simulation result when an additional program is applied to the second candidate ECU to be determined, a condition value (necessary condition value) for the functional placement necessary condition for the placement condition item, and a condition value (sufficient condition value) for the functional placement sufficient condition for the placement condition item. However, if the evaluation value is less than or equal to the sufficient condition value (evaluation value ≦ sufficient condition value), the fulfillment rate is 1.0. If the evaluation value is greater than or equal to the necessary condition value (evaluation value ≧ necessary condition value), the fulfillment rate is 0.0. By using the fulfillment rate for each placement condition item calculated for one or more extracted second candidate ECUs (second candidate ECUs listed in the secondary list of placement candidates), the control unit of the in-vehicle device can efficiently identify an ECU to which the function is to be placed from a comprehensive perspective of the multiple placement condition items.

[0024] (8) In an in-vehicle device according to one aspect of the present disclosure, each of the placement condition items is associated with a weighting coefficient according to its importance, and the control unit calculates the sum of the values ​​obtained by multiplying the fulfillment rate of each of the placement condition items by the weighting coefficient for each of the second candidate ECUs, and identifies the second candidate ECU with the largest sum as the ECU to which the function is to be placed.

[0025] In this embodiment, each placement condition item is associated with a weighting factor corresponding to the importance of the software function when the additional program is executed on the vehicle. That is, a weighting factor is assigned to the name (placement condition item name) of each placement condition item, which uniquely identifies each placement condition item. The control unit of the in-vehicle device calculates the sum (Σ(fulfillment rate × weighting factor)) of the values ​​obtained by multiplying each fulfillment rate derived based on simulation results, etc., by the corresponding weighting factor for each second candidate ECU, and identifies the second candidate ECU with the largest sum (MaxΣ(fulfillment rate × weighting factor)) as the function placement ECU. This allows the function placement ECU to be identified taking into account the importance of multiple placement condition items, thereby enabling optimal placement (function placement) of the software function implemented by the additional program.

[0026] (9) In an in-vehicle device according to one aspect of the present disclosure, the functional placement conditions include at least one of a memory usage rate, a CPU usage rate, an allowable delay time, a maximum startup time, a bus load rate in an in-vehicle network installed in the vehicle, and a relay delay time in the in-vehicle ECU.

[0027] In this aspect, the layout condition items in the functional layout conditions (functional layout necessary conditions and functional layout sufficient conditions) include at least one of the memory usage rate, CPU usage rate, allowable delay time, maximum startup time, bus load rate in the in-vehicle network installed in the vehicle, and relay delay time in the in-vehicle ECU, and correspond to items that indicate a system evaluation value for the entire vehicle when the additional program is applied to the in-vehicle ECU. In this way, the functional layout conditions include, as layout condition items, not only evaluation values ​​based on the individual performance of the in-vehicle ECU, but also system evaluation values ​​for the entire vehicle, such as the communication load in the in-vehicle network, so that software functional layout can be planned in consideration of overall optimization of the in-vehicle system.

[0028] (10) A program according to one aspect of the present disclosure causes a computer that acquires an additional program transmitted from an external server outside the vehicle and performs processing to apply the additional program to an onboard ECU mounted on the vehicle to acquire information regarding a function placement ECU identified based on a determination result regarding necessary resource conditions and function placement conditions among multiple onboard ECUs mounted on the vehicle, and to execute processing to relay the additional program acquired from the external server to the function placement ECU.

[0029] In this aspect, a program can be provided that causes a computer to execute an additional program obtained from an external server as an in-vehicle device that efficiently identifies an ECU installed in a vehicle when the ECU is to be applied to the additional program.

[0030] (11) An information processing method according to one aspect of the present disclosure includes having a computer that acquires an additional program transmitted from an external server outside the vehicle and performs processing to apply the additional program to an onboard ECU mounted on the vehicle, acquire information regarding a function placement ECU identified based on a determination result regarding required resource conditions and function placement conditions among multiple onboard ECUs mounted on the vehicle, and execute a process to relay the additional program acquired from the external server to the function placement ECU.

[0031] In this aspect, an information processing method can be provided in which a computer is caused to execute an additional program obtained from an external server as an in-vehicle device that efficiently identifies an ECU installed in a vehicle when the ECU is applied to the additional program.

[0032] [Details of the Embodiments of the Present Disclosure] The present disclosure will be specifically described with reference to the drawings illustrating the embodiments. An in-vehicle device 2 according to the embodiments of the present disclosure will be described below with reference to the drawings. Note that the present disclosure is not limited to these examples, but is defined by the claims, and is intended to include all modifications within the meaning and scope equivalent to the claims.

[0033] (Embodiment 1) Hereinafter, an embodiment will be described with reference to the drawings. Fig. 1 is a schematic diagram illustrating the configuration of an in-vehicle system including an in-vehicle device according to embodiment 1. Fig. 2 is a block diagram illustrating the physical configuration of the in-vehicle device. The in-vehicle system S includes an extra-vehicle communication device 1 and an in-vehicle device 2 mounted on a vehicle C, and transmits an additional program (OTA module) acquired from an external server SV1 (program providing device, OTA server) connected via an extra-vehicle network N to an in-vehicle ECU 3 (Electronic Control Unit) mounted on the vehicle C.

[0034] The external server SV1 is a computer such as a server connected to an external network N, such as the Internet or a public line network, and includes 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 SV1 stores programs or data for controlling the in-vehicle ECU 3, which have been created by the manufacturer of the in-vehicle ECU 3, etc. The programs or data are transmitted to the vehicle C as additional programs or update programs and are used to add or update programs or data in the in-vehicle ECU 3 installed in the vehicle C, thereby adding software functions to the vehicle C. The external server SV1 (program providing device) configured in this manner is also referred to as an OTA (Over The Air) server.

[0035] The in-vehicle device 2 functions as an OTA master that transmits additional programs and the like acquired from the external server SV1 to the in-vehicle ECU 3 to which the additional programs are to be applied, and transmits an activation instruction for applying the transmitted additional programs to the in-vehicle ECU 3. When identifying the in-vehicle ECU 3 to which the additional programs are to be applied, the in-vehicle device 2 functioning as the OTA master identifies the in-vehicle ECU 3 as the ECU to which the functions are to be applied, taking into consideration the suitability of the software function allocation resulting from the application of the additional program.

[0036] Hereinafter, a program will be described as including program code including control syntax and the like for processing by the on-board ECU 3, and an external file containing data referenced when the program code is executed. When transmitting an additional program or the like, the external file containing the program code and data is transmitted from the external server SV1, for example, as an encrypted archive file. When transmitting an additional program, the external server SV1 may generate a package (OTA module) containing the additional program and transmit the generated package (OTA module) to the vehicle C. The package (OTA module) may include, for example, package information (campaign information, OTA event) that is information related to the program addition (software function deployment), the additional program to be the target of the software function deployment, and various evaluation conditions (required resource conditions, function deployment conditions) for making a determination regarding the software function deployment.

[0037] The vehicle C is equipped with an exterior communication device 1, an in-vehicle device 2, and a plurality of in-vehicle ECUs 3 for controlling various in-vehicle devices. The exterior 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 4 that supports a communication protocol such as CAN (Control Area Network) or Ethernet (registered trademark).

[0038] The exterior-vehicle communication device 1 includes an exterior-vehicle communication unit (not shown) and an input / output I / F (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 Wi-Fi (registered trademark), and transmits and receives data to and from an external server SV1 via an antenna 11 connected to the exterior-vehicle communication unit. Communication between the exterior-vehicle communication device 1 and the external server SV1 is performed via an exterior-vehicle network N, such as a public line network or the Internet.

[0039] 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 separate device from the in-vehicle device 2, and these devices are communicatively connected via the input / output I / F or the like, but this is not limiting. 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 via an in-vehicle network 4 such as a CAN.

[0040] The in-vehicle device 2 includes a control unit 20, a storage unit 23, an input / output I / F 21, and an in-vehicle communication unit 22. The in-vehicle device 2 is configured to acquire an additional program (OTA module) received by the exterior communication device 1 from the external server SV1 via wireless communication, and transmit the additional program to the in-vehicle ECU 3 (function-assignment ECU) determined as the function-assignment destination via the in-vehicle network 4. That is, the in-vehicle device 2 functions as an OTA master (update device) that determines the function-assignment ECU and controls program addition (software function assignment) to the function-assignment ECU. Note that the determination of the function-assignment ECU is not limited to being performed by the in-vehicle device 2; the external server SV1 may determine the function-assignment ECU using vehicle information transmitted from the in-vehicle device 2.

[0041] The in-vehicle device 2 is a gateway (in-vehicle relay device) that manages multiple bus systems (segments), such as the in-vehicle ECU 3 for a control system, the in-vehicle ECU 3 for a safety system, and the in-vehicle ECU 3 for a body system, and relays communications 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 41 constituting the multiple buses (segments), and the multiple communication lines 41 (segments) aggregated by the in-vehicle device 2 constitute an in-vehicle network 4. The in-vehicle device 2 functions as a CAN gateway for relaying the CAN protocol and as a Layer 2 switch or Layer 3 switch for relaying the TCP / IP protocol. In addition to relaying communications, the in-vehicle device 2 may also function 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 in-vehicle devices such as actuators connected to the in-vehicle device 2. Alternatively, the in-vehicle device 2 may be configured as a functional part of a body ECU that controls the entire vehicle C. Alternatively, the in-vehicle device 2 may be an integrated ECU that is configured with a central control device such as a vehicle computer and performs overall control of the vehicle C.

[0042] 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 processes and calculation processes by reading and executing a control program P (program product) and data pre-stored in the memory unit 23.

[0043] The storage unit 23 is composed of 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 read-only memory (EEPROM), or a flash memory. The storage unit 23 pre-stores a control program P and data referenced when processing vehicle information, etc., as described below. The storage unit 23 also stores various data acquired by the control unit 20 from an external server SV1. The storage unit 23 also stores various intermediate data generated when the control unit 20 executes various arithmetic processes, simulation processes, etc. The control program P (program product) stored in the storage unit 23 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.

[0044] The input / output I / F 21 is a communication interface for, for example, serial communication, similar to the input / output I / F of the exterior communication device 1. Via the input / output I / F, the in-vehicle device 2 is communicably connected to the exterior communication device 1, a display device such as a display, an IG switch that starts or stops the vehicle C, or the like.

[0045] The in-vehicle communication unit 22 is an input / output interface that uses 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 that are connected to the in-vehicle network 4 via the in-vehicle communication unit 22. A plurality of in-vehicle communication units 22 (three in this embodiment) are provided, and each in-vehicle communication unit 22 is connected to a communication line 41 (segment, CAN bus) that constitutes the in-vehicle network 4.

[0046] The in-vehicle ECU 3 includes a control unit (CPU), a storage unit, and an in-vehicle communication unit, similar to the in-vehicle device 2. The storage unit 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 read-only memory (EEPROM), or a flash memory, and stores programs or data for the in-vehicle ECU 3. This program or data is transmitted from a program providing device and is added by a program relayed by the in-vehicle device 2. The in-vehicle communication unit 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.

[0047] FIG. 3 is a flowchart illustrating the processing (main) of the control unit 20 of the in-vehicle device 2. FIG. 4 is a flowchart illustrating the processing (function allocation determination) of the control unit 20 of the in-vehicle device 2. FIG. 5 is a flowchart illustrating the processing (function allocation resource condition determination) of the control unit 20 of the in-vehicle device 2. FIG. 6 is a flowchart illustrating the processing (function allocation destination ECU determination) of the control unit 20 of the in-vehicle device 2. When the control unit 20 of the in-vehicle device 2 executes the processing of FIG. 3 as a main routine, it may execute each processing in the main routine etc. as a subroutine of FIG. 4 to FIG. 6. The control unit 20 of the in-vehicle device 2 steadily executes the following processing, for example, when the vehicle C is stopped (for example, the IG switch is off).

[0048] FIG. 7 is an explanatory diagram illustrating items related to the system evaluation value (system criteria information, weighting coefficients, etc.). FIG. 8 is an explanatory diagram illustrating items related to the required resources of the target function. FIG. 9 is an explanatory diagram illustrating items related to the resource information of the candidate ECUs. FIG. 10 is an explanatory diagram illustrating items related to the target function feasibility evaluation value. FIG. 11 is an explanatory diagram illustrating items related to the evaluation signal access information. FIG. 12 is an explanatory diagram illustrating items related to the evaluation function layout information. FIG. 13 is an explanatory diagram illustrating items related to the in-vehicle network configuration information. The control unit 20 of the in-vehicle device 2 stores various pieces of information defined in FIGS. 8 to 13 in the memory unit 23. When performing a series of processes in this embodiment, the control unit 20 of the in-vehicle device 2 may store these various pieces of information in the memory unit 23 as intermediate data for various calculations.

[0049] The control unit 20 of the in-vehicle device 2 detects an OTA start event (S1). The control unit 20 of the in-vehicle device 2 periodically or constantly communicates with an external server SV1 (OTA server) and detects the occurrence of the OTA start event by acquiring information related to the OTA start event, such as campaign information related to an additional program or an update program for executing a newly added software function.

[0050] The control unit 20 of the in-vehicle device 2 determines the functional layout of the OTA module, which is an additional program (S2). Detecting an OTA start event triggers the control unit 20 of the in-vehicle device 2 to start processing for performing functional layout of the OTA module (additional program, etc.) that is the target of the OTA start event. The control unit 20 of the in-vehicle device 2 performs a series of processes shown in FIG. 4 as the processing of S2.

[0051] The control unit 20 of the in-vehicle device 2 acquires vehicle information (S201). Information regarding all in-vehicle ECUs 3 installed in the vehicle C is periodically or constantly collected by the control unit 20 of the in-vehicle device 2 and stored as vehicle information in the storage unit 23. The vehicle information includes the CPU model, CPU operating frequency, memory model, memory storage capacity and available memory space, the type of program being executed (software part number, software function), the type of operating system (OS) installed, the presence or absence of a virtual environment (VM), and the physical layer protocol of the installed communication unit. This information regarding the in-vehicle ECUs 3 may be stored in the storage unit 23 in table format, for example, as a candidate ECU resource information table shown in FIG. 9. The candidate ECU resource information table includes management items such as ECU name, VM name, installed ROM capacity, available ROM capacity, installed CPU, operating frequency, installed RAM capacity, and available RAM capacity, and stores the corresponding resource information in the corresponding in-vehicle ECU 3.

[0052] The vehicle information may further include evaluation signal access information as information regarding the type (name) and transmission period of a signal output by each on-board ECU 3. The evaluation signal access information may be stored in the storage unit 23 in table format, for example, as an evaluation signal access information table shown in FIG. 11. The evaluation signal access information table includes management items such as signal name, transmission period, and ECU name, and is defined in a matrix. The evaluation signal access information table stores, for each defined signal name (signal A, signal B, obstacle proximity information, vehicle C speed, brake output instruction, meter display instruction, audio output instruction), a processing mode (R: input, W: output) performed by the on-board ECU 3 (ECU name: control 001, control 002, autobrake control, sonar ECU, meter control, audio control, brake control).

[0053] The vehicle information may further include evaluation function layout information as information regarding functions (software functions) performed by each of the on-board ECUs 3 mounted on the vehicle C. The evaluation function layout information may be stored in the storage unit 23 in a table format, for example, as an evaluation function layout information table shown in Fig. 12. The evaluation function layout information table includes, as management items, for example, an ECU name that uniquely identifies the on-board ECU 3, a VM name that indicates the virtual environment running in the on-board ECU 3, and the name of the function performed by the on-board ECU 3.

[0054] The vehicle information may further include in-vehicle network configuration information as information about the in-vehicle ECUs 3 connected to the in-vehicle network 4. The in-vehicle network configuration information may be stored in the storage unit 23 in table format, for example, as an in-vehicle network configuration information table shown in Fig. 13. The in-vehicle network configuration information table includes, as management items, for example, a parent bus name that uniquely identifies the communication line 41 to which the in-vehicle ECU 3 is connected, the name of the connected in-vehicle ECU 3 (ECU name), the name of the virtual environment (VM name) running on the in-vehicle ECU 3, and a sub-bus name that identifies the communication line 41 arranged below the parent bus name in a cascade configuration or the like in the communication line 41. As will be described in detail later, the control unit 20 of the in-vehicle device 2 uses the evaluation signal access information, evaluation function layout information, and in-vehicle network configuration information to perform a communication simulation in the event that software function layout is performed (an additional program is applied) on one of the in-vehicle ECUs (candidate ECUs), and derives evaluation values ​​such as the CAN bus load rate (network load rate) and CAN relay delay (communication latency) in the in-vehicle network 4.

[0055] The control unit 20 of the in-vehicle device 2 acquires information about the required resources of the target function, including the required resource conditions and function placement conditions of the additional program (S202). The control unit 20 of the in-vehicle device 2 acquires information about the required resources of the target function, including the required resource conditions and function placement conditions of the additional program that is the target of software function placement, from the external server SV1 (OTA server). For the in-vehicle ECU 3 on which software function placement is performed, the conditions (required resource conditions) related to hardware resources such as the CPU or memory are indicated in, for example, a required resource table for the target function shown in FIG. 8. The required resource table for the target function includes, as management items, the module name (name of the OTA module: for example, automatic brake control), required ROM capacity, number of initialization execution steps, number of periodic execution steps, corresponding CPU, required RAM capacity, and allowable control delay time.

[0056] The execution time is calculated by combining the number of initialization execution steps and the number of periodic execution steps with, for example, the CPU operation clock (frequency) of the in-vehicle ECU 3 where the module is to be installed. If modules compatible with multiple CPU types are prepared in advance, the compatible CPUs may all be listed, or if the module is an execution image executed on a virtual machine such as JAVA (registered trademark), a value (such as ANY) indicating that there is no restriction on the CPU type may be written.

[0057] The allowable control delay time indicates the maximum allowable response time from when the on-board ECU 3 generates or receives a sensor signal acquired for control purposes until when the on-board ECU 3 outputs a control signal to an on-board load, such as an actuator, directly connected to the on-board ECU 3. The allowable control delay time (maximum allowable response time) may include, as condition values, a necessary condition value (e.g., 500 ms or less) and a sufficient condition value (e.g., 200 ms or less) that is more conditionally restrictive (stricter) than the necessary condition value. The control unit 20 of the on-board device 2 may determine whether the on-board ECU 3 meets the required resource conditions using two condition values, the sufficient condition value and the necessary condition value, such as the allowable control delay time.

[0058] The control unit 20 of the in-vehicle device 2 extracts candidate ECUs that can be candidates for the destination of the function allocation (S203). Using the vehicle information stored in the storage unit 23, the control unit 20 of the in-vehicle device 2 evaluates, for all in-vehicle ECUs 3 mounted on the vehicle C, each evaluation item of required resource conditions, which mainly defines conditions related to the hardware resources of the in-vehicle ECUs 3, i.e., determines whether each is present or absent. The control unit 20 of the in-vehicle device 2 may determine whether each evaluation item (static resource condition) defined as a single condition value, such as the required ROM capacity, the number of initialization execution steps, the number of periodic execution steps, a compatible CPU, and the required RAM capacity, is present or absent in the evaluation items of the required resource conditions.

[0059] The control unit 20 of the in-vehicle device 2 uses the vehicle information stored in the storage unit 23 to compare the CPU model, CPU operating frequency, memory model, memory storage capacity and available capacity, type of running program (software part number, software function), type of OS (operating system) implemented, presence or absence of virtual environment (VM), and physical layer protocol of the implemented communication unit with the judgment values ​​of the evaluation items of the required resource conditions for each in-vehicle ECU 3, and adds in-vehicle ECUs 3 that satisfy all of these evaluation items as candidate ECUs to the primary list of candidate placement destinations. By generating the primary list of candidate placement destinations in this way, one or more in-vehicle ECUs 3 (candidate ECUs) that correspond (satisfy the requirements) as a standalone hardware resource for software function deployment (application of additional programs) according to the evaluation items of the required resource conditions are included in the primary list of candidate placement destinations. The multiple in-vehicle ECUs 3 (candidate ECUs) included in the primary list of placement candidates may be listed, for example, in the order in which they were determined by the control unit 20 of the in-vehicle device 2, or may be listed in order (ascending order, etc.) based on an identifier such as an ECU-ID that uniquely identifies the in-vehicle ECU 3.

[0060] The control unit 20 of the in-vehicle device 2 sequentially selects candidate ECUs included in the primary list of placement candidates (S204). The control unit 20 of the in-vehicle device 2 sequentially selects candidate ECUs included in the primary list of placement candidates by, for example, referring to the primary list of placement candidates generated and stored in the storage unit 23, starting from the beginning of the line. The control unit 20 of the in-vehicle device 2 may additionally assign a flag value indicating that the candidate ECU has been selected to the primary list of placement candidates in this manner, thereby managing the selected candidate ECUs in a manner that allows distinction between selected candidate ECUs and unselected candidate ECUs.

[0061] The control unit 20 of the in-vehicle device 2 determines the necessary resource conditions for the selected candidate ECU (S205). As the processing of S205, the control unit 20 of the in-vehicle device 2 performs a series of processing shown in Fig. 5 (determining function allocation resource conditions). Each candidate ECU included in the primary list of allocation candidates satisfies the type or specification requirements (static resource conditions) of the in-vehicle ECU 3 required for software function allocation, such as the type and operating frequency of the CPU required to execute the additional program, the capacity and available space of volatile and non-volatile memory, the presence or absence of a virtual environment, the type of physical layer protocol, the type of OS implemented, etc.

[0062] The control unit 20 of the in-vehicle device 2 further performs the following processing to derive evaluation values ​​for each of the various evaluation items (dynamic resource conditions) when executing the additional program, taking into account the memory area and CPU usage time used by the various programs or applications already being executed (applied) on the candidate ECU when allocating software functions to the candidate ECU.

[0063] To derive the evaluation values ​​for each of these evaluation items, the control unit 20 of the in-vehicle device 2 may model the hardware configuration of the in-vehicle ECU 3 and perform a simulation by running additional programs and existing programs on the model. The evaluation items include, for example, volatile and non-volatile memory usage (ROM usage, RAM usage), maximum CPU usage, or maximum startup time. The control unit 20 of the in-vehicle device 2 may also determine whether a condition related to a maximum control response time (allowable control delay time) is met as an evaluation value.

[0064] The control unit 20 of the in-vehicle device 2 may use condition values ​​corresponding to the evaluation items when determining whether the conditions for each of these evaluation items are met. The condition values ​​may include necessary condition values ​​and sufficient condition values ​​that are conditionally more limited than the necessary condition values, and the control unit 20 of the in-vehicle device 2 may determine whether the evaluation value derived by simulation or the like for each evaluation item satisfies or does not satisfy the necessary condition values ​​and the sufficient condition values.

[0065] The control unit 20 of the in-vehicle device 2 determines whether a memory usage rate condition is satisfied among the necessary resource conditions (S2051). The control unit 20 of the in-vehicle device 2 may determine, for example, the usage rates of a volatile memory (RAM) and a non-volatile memory (ROM) as the memory usage rate condition. The memory usage rate condition may be stored in the storage unit 23 in a table format, such as the items related to the system evaluation value shown in FIG. 7. The items related to the system evaluation value include system criteria information that defines the memory usage rate condition, etc.

[0066] The system criteria information is stored, for example, in a table format (system criteria information table). The system criteria information table includes evaluation items, necessary conditions, and sufficient conditions as management items, which correspond to function placement conditions. The evaluation items in the system criteria information table (function placement conditions) include, for example, CAN bus load factor, CAN frame relay delay, ROM usage rate, RAM usage rate, maximum startup time, and maximum CPU usage rate. For each of these evaluation items, a necessary condition (function placement necessary condition) and a sufficient condition (function placement sufficient condition) that is more conditionally restrictive (stricter) than the necessary condition are defined.

[0067] In determining the usage rates of the volatile memory (RAM) and non-volatile memory (ROM), the control unit 20 of the in-vehicle device 2 derives the memory usage rates when software function allocation (application of additional programs) is performed on the selected candidate ECU by referring to the system criteria information table. The control unit 20 of the in-vehicle device 2 identifies existing programs already applied to the candidate ECU by referring to vehicle information. The control unit 20 of the in-vehicle device 2 may then calculate the memory usage rates (ROM usage rate, RAM usage rate) when the additional programs are applied based on the memory usage amount and memory capacity occupied by each program, or may derive the memory usage rates using simulations, etc.

[0068] The control unit 20 of the in-vehicle device 2 may store the derived memory usage rates (ROM usage rate, RAM usage rate) as evaluation values ​​in the table of system evaluation values ​​described above, thereby storing the derived evaluation values ​​(ROM usage rate, RAM usage rate) for each candidate ECU in the storage unit 23 as items related to the system evaluation value shown in Fig. 7. The control unit 20 of the in-vehicle device 2 may determine whether the derived evaluation values ​​(ROM usage rate, RAM usage rate) satisfy two condition values, a sufficient condition value and a necessary condition value.

[0069] If the memory utilization rate condition is met (S2051: YES), the control unit 20 of the in-vehicle device 2 determines whether the maximum CPU utilization rate condition, which is one of the necessary resource conditions, is met (S2052). If the derived evaluation values ​​(ROM utilization rate, RAM utilization rate) for a candidate ECU meet the necessary condition values, the control unit 20 of the in-vehicle device 2 determines whether the candidate ECU meets the maximum CPU utilization rate condition. For the maximum CPU utilization rate condition, sufficient conditions (functional layout sufficient conditions) and necessary conditions (functional layout necessary conditions) are also defined in the system criteria information table.

[0070] The control unit 20 of the in-vehicle device 2 may identify existing programs already applied to the candidate ECU by referring to vehicle information, and then calculate the maximum CPU utilization rate when the additional program is applied based on the time slice value, etc., of the CPU used by each program and the operating frequency, or derive it using a simulation, etc. The control unit 20 of the in-vehicle device 2 may store the derived maximum CPU utilization rate as an evaluation value in the table of system evaluation values ​​described above, and thereby store it in the storage unit 23 for each candidate ECU as an item related to the system evaluation value shown in FIG. 7, for example. The control unit 20 of the in-vehicle device 2 may determine whether the derived evaluation value (maximum CPU utilization rate) satisfies two condition values, a sufficient condition value and a necessary condition value.

[0071] If the maximum CPU utilization rate condition is met (S2052: YES), the control unit 20 of the in-vehicle device 2 determines whether the maximum startup time condition in the necessary resource conditions is met (S2053). If the derived evaluation value (maximum CPU utilization rate) for the candidate ECU meets the necessary condition value, the control unit 20 of the in-vehicle device 2 determines whether the candidate ECU meets the maximum startup time condition.

[0072] The control unit 20 of the in-vehicle device 2 may identify existing programs already applied to the candidate ECU by referring to vehicle information, and then calculate the maximum startup time when the additional program is applied based on the time slice value, etc., of the CPU used by each program and the operating frequency, or derive the maximum startup time using a simulation, etc. The control unit 20 of the in-vehicle device 2 may store the derived maximum startup time as an evaluation value in the table of system evaluation values ​​described above, and thereby store the derived maximum startup time in the storage unit 23 for each candidate ECU as an item related to the system evaluation value shown in FIG. 7, for example. The control unit 20 of the in-vehicle device 2 may determine whether the derived evaluation value (maximum startup time) satisfies two condition values, a sufficient condition value and a necessary condition value.

[0073] If the maximum startup time condition is met (S2053: YES), the control unit 20 of the in-vehicle device 2 notifies the selected candidate ECU that the required resource condition is met (True) (S2054). In this embodiment, if a candidate ECU meets the maximum startup time condition, the candidate ECU meets all of the memory usage rate (ROM usage rate, RAM usage rate), maximum CPU usage rate, and maximum startup time conditions. In other words, the candidate ECUs listed in the primary list of placement candidates not only meet the ROM feasibility, RAM feasibility, and CPU feasibility required as hardware resource requirements, but also meet at least the required condition values ​​for the memory usage rate (ROM usage rate, RAM usage rate), maximum CPU usage rate, and maximum startup time conditions. The control unit 20 of the in-vehicle device 2 may store in the memory unit 23, for example, a target function feasibility evaluation value table in the form of a table shown in Figure 10, judgment result information (target function feasibility evaluation value, system evaluation value) that associates evaluation values ​​and judgment results (sufficient, necessary) for various evaluation items for the candidate ECU.

[0074] If the memory usage rate condition is not met (S2051: NO), if the maximum CPU usage rate condition is not met (S2052: NO), or if the maximum startup time condition is not met (S2053: NO), the control unit 20 of the in-vehicle device 2 notifies the selected candidate ECU that the required resource conditions are not met (False) (S2055).If the selected candidate ECU does not meet the required condition value for any one of the memory usage rate condition, the maximum CPU usage rate condition, and the maximum startup time condition, the control unit 20 of the in-vehicle device 2 notifies the candidate ECU that the required resource conditions are not met (False) and stores this information in the storage unit 23.

[0075] The control unit 20 of the in-vehicle device 2 determines whether the selected candidate ECU satisfies the necessary resource conditions (S206). Based on the above-described determination result, the control unit 20 of the in-vehicle device 2 refers to the determination result stored in the storage unit 23 to determine whether the selected candidate ECU satisfies at least the necessary condition values ​​(True) for all of the condition items of the necessary resource conditions (memory usage rate (ROM usage rate, RAM usage rate), maximum CPU usage rate, and maximum startup time condition). If the selected candidate ECU does not satisfy the necessary resource conditions (S206: NO), the control unit 20 of the in-vehicle device 2 performs loop processing to execute the processing from S204 again.

[0076] If the required resource conditions are met (S206: YES), the control unit 20 of the in-vehicle device 2 calculates a system evaluation value by executing a communication simulation (S207). If the required resource conditions are met, the control unit 20 of the in-vehicle device 2 calculates a system evaluation value for the condition items (system evaluation items) of the functional layout conditions by executing a communication simulation under an operating environment in which the selected candidate ECU and the candidate ECU are connected to the in-vehicle network 4.

[0077] As described above, the condition items (system evaluation items) of the functional layout conditions are stored in the storage unit 23 in table format, like the items related to the system evaluation values ​​shown in Fig. 7. Among the condition items (system evaluation items) of the functional layout conditions, the evaluation values ​​(memory usage rate, maximum CPU usage rate, maximum startup time condition) of the candidate ECU alone are derived by the above-described process. The control unit 20 of the in-vehicle device 2 derives evaluation values ​​for other condition items (system evaluation items), such as the CAN bus load rate and CAN frame relay delay, in an operating environment in which the candidate ECU is connected to the in-vehicle network 4, for example, by performing a communication simulation.

[0078] When performing the communication simulation, the control unit 20 of the in-vehicle device 2 refers to various information included in the vehicle information (evaluation signal access information, evaluation function layout information, and in-vehicle network configuration information). The evaluation signal access information is stored in the storage unit 23, for example, in the form of an evaluation signal access information table in the form of a table shown in Fig. 11. The evaluation function layout information is stored in the storage unit 23, for example, in the form of an evaluation function layout information table in the form of a table shown in Fig. 12. The in-vehicle network configuration information is stored in the storage unit 23, for example, in the form of an in-vehicle network configuration information table in the form of a table shown in Fig. 13.

[0079] The control unit 20 of the in-vehicle device 2 uses this information (evaluation signal access information, evaluation function layout information, and in-vehicle network configuration information) to generate a model corresponding to the state in which software functions are allocated to the candidate ECUs, and performs a communication simulation using the model. The control unit 20 of the in-vehicle device 2 derives evaluation values ​​(system evaluation values) of the CAN bus load factor and the CAN frame relay delay based on the results of the communication simulation.

[0080] The control unit 20 of the in-vehicle device 2 may generate a model corresponding to the state in which software function allocation has been performed on the candidate ECU (i.e., the application of an additional program) by reflecting (adding) the state in which software function allocation has been performed on the candidate ECU in the evaluation signal access information, evaluation function layout information, and in-vehicle network configuration information. In this case, the control unit 20 of the in-vehicle device 2 performs a communication simulation on the virtual in-vehicle network 4 (model) using information contained in these various pieces of information, such as the network configuration of the vehicle C, the ID, period, and size of data transmitted by each in-vehicle ECU 3 or sensor, and the ID of data required by each in-vehicle ECU 3. In the communication simulation, the control unit 20 of the in-vehicle device 2 measures the amount and frequency of data transmitted and received on the virtual in-vehicle network 4 (model) to calculate values ​​such as the communication load on each communication line 41, such as a CAN bus, or the maximum delay time for each piece of data.

[0081] The control unit 20 of the in-vehicle device 2 may calculate, as the communication load rate, the proportion of the time during which data is being transmitted and received on each communication line 41 relative to the total time of the communication simulation, and calculate, as the average load rate, the average value of the communication load rates of the multiple communication lines 41. For each piece of data transmitted and received in the virtual in-vehicle network 4 (model), the control unit 20 of the in-vehicle device 2 calculates the delay time from the time when the data is transmitted from the in-vehicle ECU 3 that is the transmission source until the data is received by the in-vehicle ECU 3 that is the receiving side. The control unit 20 of the in-vehicle device 2 may calculate the delay time for all data transmitted and received in the communication simulation, and obtain the longest delay time as the maximum delay time.

[0082] When performing the communication simulation, the control unit 20 of the in-vehicle device 2 may refer to scenario information (use case DB) stored in the storage unit 23. The scenario information may be stored in the storage unit 23, for example, as a use case DB (operation database) in which various operations performed by the vehicle C and events occurring in each of these operations are associated with each other and stored.

[0083] The control unit 20 of the in-vehicle device 2 inputs input data to the virtual in-vehicle network 4 (model) using scenario information (use case DB), and acquires various output data that are output in the virtual in-vehicle network 4 (model) according to the input data. The control unit 20 of the in-vehicle device 2 manages the time in the communication simulation based on the scenario information, and repeatedly inputs and outputs data to the virtual in-vehicle network 4 (model) as time passes. The control unit 20 of the in-vehicle device 2 acquires information such as the internal state of the virtual in-vehicle network 4 (model) that changes as the scenario is executed, and may store the acquired information in the storage unit 23 as an operation log in the communication simulation, associated with the time point when the information was acquired.

[0084] When the control unit 20 of the in-vehicle device 2 generates a scenario for executing a communication simulation based on scenario information (use case DB), the scenario may include, for example, information for simulating all use cases stored in the use case DB. The control unit 20 of the in-vehicle device 2 executes all events included in the scenario and performs a communication simulation of all use cases for the virtual in-vehicle network 4 (model). An operation log output by executing the communication simulation may include, for all steps included in the scenario, information such as output data of the virtual in-vehicle network 4 (model) or internal states of the in-vehicle ECUs 3 included in the virtual in-vehicle network 4 (model), such as CPU usage rates. The operation log may also include, for all steps included in the scenario, information such as output data of the virtual in-vehicle network 4 (model) or internal states of all in-vehicle ECUs 3 included in the virtual in-vehicle network 4 (model).

[0085] The control unit 20 of the in-vehicle device 2 calculates the load factor or communication delay of the in-vehicle network 4 based on the operation log obtained as a result of the communication simulation. The control unit 20 of the in-vehicle device 2 may calculate, for each communication bus included in the virtual in-vehicle network 4 (model), the proportion of the time during which data was transmitted and received on the communication bus relative to the total time during which the communication simulation was performed, and calculate the highest proportion or an average value of multiple proportions among all the communication buses as the load factor of the in-vehicle network 4. Alternatively, the control unit 20 of the in-vehicle device 2 may calculate, for all data transmitted and received in the communication simulation, the time from when the data is transmitted at the source to when it is received at the destination (delay time), and determine the network communication delay as the maximum value, average value, or the like of multiple delay times calculated for all the data. By performing the above-mentioned communication simulation, the control unit 20 of the in-vehicle device 2 may derive evaluation values ​​(system) for various system evaluation items, such as the CAN bus load rate (maximum CAN bus load rate), the CAN frame relay delay (maximum CAN relay delay), the network load rate in the in-vehicle network 4, communication latency, or traffic volume, and store the evaluation values ​​in the memory unit 23, for example, by storing them in a system evaluation value table for each candidate ECU.

[0086] The control unit 20 of the in-vehicle device 2 determines whether the system evaluation value satisfies the functional layout sufficient conditions (S208). The control unit 20 of the in-vehicle device 2 determines whether, for each evaluation value (system evaluation value) of the system evaluation items derived for the selected candidate ECU, all of the predetermined sufficient conditions (functional layout sufficient conditions) for the evaluation item are satisfied. The evaluation items to be determined in this process include, for example, memory usage (ROM usage, RAM usage), maximum CPU usage, maximum startup time, maximum control response time (permissible control delay time), maximum CAN bus load factor, and maximum CAN relay delay. The evaluation values ​​(system evaluation values) for these evaluation items are derived by communication simulation or the like. The control unit 20 of the in-vehicle device 2 determines whether the system evaluation value for each system evaluation item satisfies the sufficient condition value, for example, by referring to the necessary conditions and sufficient conditions included in the system evaluation value table.

[0087] If the system evaluation value satisfies the functional placement sufficient condition (S208: YES), the control unit 20 of the in-vehicle device 2 determines the ECU to which the function is to be placed from among the candidate ECUs that satisfy the functional placement sufficient condition (S2081). If all evaluation values ​​(system evaluation values) for the system evaluation items of the selected candidate ECU satisfy the sufficient condition (satisfy the sufficient condition value), the control unit 20 of the in-vehicle device 2 determines (identifies) the candidate ECU as the ECU to which the function is to be placed. By determining (identifying) the candidate ECU as the ECU to which the function is to be placed in this process, the control unit 20 of the in-vehicle device 2 ends the series of processes related to the determination of the OTA module functional placement. As a result, the control unit 20 of the in-vehicle device 2 suspends the process related to the determination of the OTA module functional placement without performing the determination process on all candidate ECUs included in the primary list of placement candidates.

[0088] If the system evaluation value does not satisfy the functional layout sufficient condition (S208: NO), the control unit 20 of the in-vehicle device 2 determines whether the system evaluation value satisfies the functional layout necessary condition (S209). If all evaluation values ​​(system evaluation values) in the system evaluation items of the selected candidate ECU do not satisfy the sufficient condition of any one evaluation item, the control unit 20 of the in-vehicle device 2 determines whether the system evaluation value of the candidate ECU satisfies the functional layout necessary condition.

[0089] If the system evaluation value satisfies the functional layout requirement (S209: YES), the control unit 20 of the in-vehicle device 2 adds the candidate ECU (second candidate ECU) to the secondary list of placement candidates (S210). If all evaluation values ​​(system evaluation values) in the system evaluation items of the selected candidate ECU satisfy the requirement (satisfy the requirement value), the control unit 20 of the in-vehicle device 2 identifies the candidate ECU as a second candidate ECU and adds it to the secondary list of placement candidates. As a result, the secondary list of placement candidates lists in-vehicle ECUs 3 (second candidate ECUs) that satisfy the requirement (functional layout requirement) for all evaluation values ​​(system evaluation values) in the system evaluation items.

[0090] If the system evaluation value does not satisfy the functional layout requirement (S209: NO), or after execution of S210, the control unit 20 of the in-vehicle device 2 determines whether evaluation of all candidate ECUs has been completed (S211). If the system evaluation value does not satisfy the functional layout requirement, or after execution of S210, the control unit 20 of the in-vehicle device 2 determines whether evaluation of all candidate ECUs has been completed, i.e., whether there are any unevaluated candidate ECUs, by referring to the primary list of candidate placement locations. The control unit 20 of the in-vehicle device 2 can identify unevaluated candidate ECUs by checking flag values ​​indicating selection that have been added to the primary list of candidate placement locations. If evaluation of all candidate ECUs has not been completed (S211: NO), the control unit 20 of the in-vehicle device 2 performs loop processing to execute the processing from S204 again.

[0091] When the evaluation of all the candidate ECUs is completed (S211: YES), the control unit 20 of the in-vehicle device 2 determines an ECU in which the function is to be disposed from the secondary list of candidate ECUs (S212). As the process of S212, the control unit 20 of the in-vehicle device 2 performs a series of processes shown in FIG. 6 (determining an ECU in which the function is to be disposed).

[0092] The control unit 20 of the in-vehicle device 2 sequentially acquires information about second-candidate ECUs from the secondary list of placement candidates (S2121). The control unit 20 of the in-vehicle device 2 sequentially acquires information about one or more second-candidate ECUs listed in the secondary list of placement candidates, for example, in the order in which they are listed. For each second-candidate ECU included in the secondary list of placement candidates, a system evaluation value table, for example, as shown in FIG. 7, is stored in the storage unit 23. The system evaluation value table stores various derived evaluation values ​​(system evaluation values), judgment values ​​(necessary condition values, sufficient condition values), and weighting coefficients. The control unit 20 of the in-vehicle device 2 acquires information about a second-candidate ECU listed in the secondary list of placement candidates by referencing the system evaluation value table in which the evaluation value of the second-candidate ECU is stored.

[0093] The control unit 20 of the in-vehicle device 2 calculates the fulfillment rate for each item of the system evaluation value (S2122). The control unit 20 of the in-vehicle device 2 calculates the fulfillment rate for each evaluation item in the system evaluation value table based on the derived evaluation value, necessary condition value, and sufficient condition value: "Fulfillment rate = 1 - {(evaluation value - sufficient condition value) / (necessary condition value - sufficient condition value)}." The control unit 20 of the in-vehicle device 2 stores the calculated evaluation value for each evaluation item in the fulfillment rate field of the system evaluation value table, thereby storing it in the storage unit 23.

[0094] The control unit 20 of the in-vehicle device 2 calculates a functional layout suitability evaluation value using the fulfillment rate and weighting coefficient of each item (S2123). The control unit 20 of the in-vehicle device 2 calculates the total value (Σ(fulfillment rate×weighting coefficient)) of the values ​​obtained by multiplying each calculated evaluation value by the corresponding weighting coefficient as the functional layout suitability evaluation value. The control unit 20 of the in-vehicle device 2 stores the calculated functional layout suitability evaluation value (Σ(fulfillment rate×weighting coefficient)) in the function layout suitability evaluation value (total value) field of the system evaluation value table, thereby storing it in the storage unit 23.

[0095] The control unit 20 of the in-vehicle device 2 determines whether processing has been completed for all second candidate ECUs included in the secondary list of placement candidates (S2124). The control unit 20 of the in-vehicle device 2 may sequentially perform a determination process on the second candidate ECUs included in the secondary list of placement candidates, and determine whether processing has been completed for all second candidate ECUs based on whether processing has been completed for all second candidate ECUs listed up to the end of the list. If processing has not been completed for all second candidate ECUs (S2124: NO), the control unit 20 of the in-vehicle device 2 performs a loop process to execute the process from S2121 again.

[0096] If the process for all second candidate ECUs has been completed (S2124: YES), the control unit 20 of the in-vehicle device 2 determines the second candidate ECU with the largest function placement suitability evaluation value as the function placement destination ECU (S2125). The control unit 20 of the in-vehicle device 2 compares the function placement suitability evaluation values ​​stored in the system evaluation value tables of the second candidate ECUs stored in the storage unit 23, and determines (specifies) the second candidate ECU with the largest function placement suitability evaluation value as the function placement destination ECU.

[0097] As described above, the control unit 20 of the in-vehicle device 2 performs a three-stage determination (narrowing down) process for all in-vehicle ECUs 3 mounted on the vehicle C when determining the ECU to which the function is to be allocated. That is, in a first stage, when performing software function allocation for all in-vehicle ECUs 3 mounted on the vehicle C, the control unit 20 of the in-vehicle device 2 determines whether the in-vehicle ECUs 3 have the type or specification requirements (static resource conditions) of the CPU type or memory capacity, etc. Then, in a second stage, the control unit 20 of the in-vehicle device 2 determines whether the in-vehicle ECUs 3 have the evaluation items (memory usage rate, maximum CPU usage rate, maximum startup time) that are dynamic resource conditions in an operating state in which the in-vehicle ECUs 3 (candidate ECUs) execute existing programs when software function allocation is performed by executing additional programs.

[0098] The first and second stages are condition determinations for the in-vehicle ECU 3 alone, but the control unit 20 of the in-vehicle device 2 also performs a system evaluation that includes, as an evaluation item, the communication load and the like in an environment in which the in-vehicle ECU 3 (candidate ECU) on which the software functions have been allocated is connected to the in-vehicle network 4. In this way, by performing a condition fulfillment determination in the third stage, the control unit 20 of the in-vehicle device 2 can determine not only the operation of the in-vehicle ECU 3 (candidate ECU) alone, but also various evaluation items (system evaluation determination) in an operating environment in which the candidate ECU and other in-vehicle ECUs 3 are connected to the in-vehicle network 4, and can determine (identify) an ECU to which functions can be allocated that can achieve overall optimization in the vehicle C.

[0099] When performing the determination processes in the second stage (evaluation based on necessary resource conditions (dynamic resource conditions)) and the third stage (system evaluation based on functional layout conditions), the control unit 20 of the in-vehicle device 2 uses necessary condition values ​​and sufficient condition values, which are more conditionally restricted than the necessary condition values, as determination values ​​used in determining various evaluation items. As a result, even if there is no in-vehicle ECU 3 that satisfies the sufficient condition values ​​for all evaluation items, it is possible to determine (identify) the in-vehicle ECU 3 that has the highest evaluation value (functional layout compatibility evaluation value) among the in-vehicle ECUs 3 that satisfy all necessary condition values ​​as the ECU to which the functions are to be placed.

[0100] The control unit 20 of the in-vehicle device 2 receives the OTA module (additional program) for adding a software function from the external server SV1 (OTA server) (S3).

[0101] The control unit 20 of the in-vehicle device 2 relays the OTA module to the function-location-target ECU (S4). The control unit 20 of the in-vehicle device 2 relays (transmits) the OTA module (additional program) received (acquired) from the external server SV1 (OTA server) to the function-location-target ECU (in-vehicle ECU 3) determined (specified) in the processing of S2081 or S212. After relaying (transmitting) the OTA module (additional program) to the function-location-target ECU (in-vehicle ECU 3), the control unit 20 of the in-vehicle device 2 may transmit an activate signal or the like to the function-location-target ECU to execute the OTA module (additional program) in the function-location-target ECU.

[0102] 14 is a flowchart illustrating processing by the control unit 20 of the in-vehicle device 2 according to a second embodiment (the external server SV1 is a simulation). In this embodiment, the external server SV1 (OTA server) uses vehicle information transmitted from the in-vehicle device 2 to determine (identify) a function-distribution destination ECU, which is the in-vehicle ECU 3 to which an OTA module (additional program) transmitted to the in-vehicle device 2 is to be applied (functionally allocated). The control unit 20 of the in-vehicle device 2 obtains, from the external server SV1 (OTA server), information related to the determined function-distribution destination ECU and the OTA module (additional program).

[0103] The control unit 20 of the in-vehicle device 2 detects an OTA start event (S21). The control unit 20 of the in-vehicle device 2 performs the process of S21 in the same manner as the process S1 in the first embodiment.

[0104] The control unit 20 of the in-vehicle device 2 transmits the vehicle information to the external server SV1 (S22). The control unit 20 of the in-vehicle device 2 transmits the vehicle information stored in the storage unit 23 to the external server SV1. The vehicle information transmitted by the in-vehicle device 2 to the external server SV1 is the same as the vehicle information in the first embodiment.

[0105] The external server SV1 determines (specifies) the ECU in which the function is to be allocated by performing the same process as the process S2, etc., performed by the in-vehicle device 2 in the first embodiment using the vehicle information from the in-vehicle device 2. The external server SV1 transmits information about the determined ECU in which the function is to be allocated to the in-vehicle device 2.

[0106] The control unit 20 of the in-vehicle device 2 acquires information about the function-location-target ECU identified by the external server SV1 (S23). The control unit 20 of the in-vehicle device 2 acquires information about the function-location-target ECU identified by the external server SV1 from the external server SV1.

[0107] The control unit 20 of the in-vehicle device 2 receives the OTA module from the external server SV1 (S24). The control unit 20 of the in-vehicle device 2 relays the OTA module to the ECU where the function is to be installed (S25). The control unit 20 of the in-vehicle device 2 performs the processes of S24 to S25, similar to the processes of S3 to S4 in the first embodiment.

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

[0109] Multiple claims may be combined with each other regardless of the form of reference. The claims may contain multiple dependent claims that depend on multiple claims. Multiple dependent claims may be contained that depend on multiple dependent claims. If multiple dependent claims that depend on multiple dependent claims are not contained, this does not limit the number of multiple dependent claims that depend on multiple dependent claims.

[0110] C Vehicle S In-vehicle system SV1 External server (OTA server) N Exterior network 1 Exterior communication device 11 Antenna 2 In-vehicle device (OTA master) 20 Control unit 21 Input / output I / F 22 In-vehicle communication unit 23 Storage unit M Recording medium P Control program (program product) 3 In-vehicle ECU (candidate ECU, second candidate ECU, function allocation destination ECU) 4 In-vehicle network 41 Communication line

Claims

1. An in-vehicle device having a control unit that acquires an additional program transmitted from an external server outside the vehicle and performs processing to apply the additional program to an in-vehicle ECU mounted on the vehicle, wherein the control unit acquires information regarding a function placement destination ECU identified according to a determination result regarding necessary resource conditions and function placement conditions among a plurality of in-vehicle ECUs mounted on the vehicle, and relays the additional program acquired from the external server to the function placement destination ECU identified according to the acquired information.

2. The in-vehicle device described in claim 1, wherein the determination regarding the necessary resource conditions and the functional placement conditions is performed by the external server, and the control unit outputs vehicle information including information regarding the resources of each of the multiple in-vehicle ECUs to the external server, and obtains from the external server information regarding the ECU to which the function is to be placed that is identified by the external server based on the vehicle information and the necessary resource conditions and the functional placement conditions in the additional program.

3. The in-vehicle device according to claim 1, wherein the control unit: acquires from the external server the necessary resource conditions and the functional placement conditions required in the in-vehicle ECU or the vehicle to execute the additional program; extracts one or more of the in-vehicle ECUs that satisfy the necessary resource conditions as candidate ECUs from among the multiple in-vehicle ECUs; and identifies, from among the extracted candidate ECUs, a candidate ECU that satisfies the functional placement conditions as the ECU to which the function is to be placed.

4. The in-vehicle device according to claim 3, wherein the necessary resource conditions include at least one of a storage capacity, a CPU type, and an operating frequency of the in-vehicle ECU.

5. The in-vehicle device of claim 4, wherein the functional placement conditions include functional placement necessary conditions and functional placement sufficient conditions that are more specific than the functional placement necessary conditions, and the control unit: determines whether or not a candidate ECU that satisfies the functional placement sufficient conditions is present among the extracted candidate ECUs; if a candidate ECU that satisfies the functional placement sufficient conditions is present, identifies the candidate ECU that satisfies the functional placement sufficient conditions as the functional placement destination ECU; and if no candidate ECU that satisfies the functional placement sufficient conditions is present, determines whether or not a candidate ECU that satisfies the functional placement necessary conditions is present.

6. The in-vehicle device according to claim 5, wherein, when a plurality of candidate ECUs are extracted, the control unit sequentially determines whether or not the functional layout sufficient condition is satisfied for each of the plurality of candidate ECUs, and if it determines that the functional layout sufficient condition is satisfied for any of the candidate ECUs, it interrupts the process of determining whether the functional layout sufficient condition is satisfied without performing determination processing for any undetermined candidate ECUs that are ranked lower than any of the candidate ECUs.

7. The in-vehicle device according to claim 6, wherein the functional placement conditions include a plurality of placement condition items, and the control unit extracts candidate ECUs that satisfy the functional placement necessary conditions as second candidate ECUs, calculates a fulfillment rate for each of the placement condition items in each of the second candidate ECUs, and identifies the ECU in which the function is to be placed based on the fulfillment rate in each of the second candidate ECUs.

8. The in-vehicle device according to claim 7, wherein each of the placement condition items is associated with a weighting coefficient according to its importance, and the control unit calculates a sum of values ​​obtained by multiplying the fulfillment rate of each of the placement condition items by the weighting coefficient for each of the second candidate ECUs, and identifies the second candidate ECU with the largest sum as the ECU to which the function is to be placed.

9. The in-vehicle device according to claim 8, wherein the functional placement conditions include at least one of a memory usage rate, a CPU usage rate, an allowable delay time, a maximum startup time, a bus load rate in an in-vehicle network mounted in the vehicle, and a relay delay time in the in-vehicle ECU.

10. A program that causes a computer that receives an additional program transmitted from an external server outside the vehicle and processes the application of the additional program to an on-board ECU mounted in the vehicle to execute the following process: obtain information regarding a function placement destination ECU that is identified based on the determination results regarding necessary resource conditions and function placement conditions among a plurality of on-board ECUs mounted in the vehicle; and relay the additional program obtained from the external server to the function placement destination ECU.

11. An information processing method that causes a computer that performs processing to acquire an additional program transmitted from an external server outside the vehicle and apply the additional program to an on-board ECU mounted in the vehicle to execute the following processing: acquire information regarding a function placement destination ECU that is specified according to the determination results regarding necessary resource conditions and function placement conditions among a plurality of on-board ECUs mounted in the vehicle, and relay the additional program acquired from the external server to the function placement destination ECU.

Images