In-vehicle device, program, and information processing method
The control unit of the vehicle-mounted device efficiently determines the ECU based on necessary resources and functional configuration conditions, solving the problem of improper ECU determination in the prior art, optimizing software function configuration, making reasonable use of hardware resources, and avoiding resource shortages and reduced responsiveness.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- AUTONETWORKS TECH LTD
- Filing Date
- 2024-12-02
- Publication Date
- 2026-07-10
AI Technical Summary
Existing technologies fail to efficiently identify the ECU when applying additional programs obtained from an external server to any ECU in a vehicle, resulting in wasted resources and decreased responsiveness.
The control unit of the vehicle-mounted device efficiently determines the target ECU for functional configuration based on the necessary resource conditions and functional configuration conditions obtained from an external server, including simulating the resources and network communication of the vehicle-mounted ECU, and optimizing the software functional configuration.
It enables efficient identification of the ECU in the vehicle, rational use of hardware resources, avoidance of resource shortages and responsiveness degradation, and ensures appropriate configuration of software functions.
Smart Images

Figure CN122374735A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to vehicle-mounted devices, programs, and information processing methods.
[0002] This application claims priority based on Japanese Application No. 2023-210516, filed on December 13, 2023, and invokes all the contents set forth in the said Japanese application. Background Technology
[0003] The vehicle is equipped with an ECU (Electronic Control Unit) for controlling onboard equipment such as engine control and drive control systems, and body systems such as air conditioning control. The ECU includes a processing unit such as an MPU, a rewritable non-volatile storage unit such as an EEPROM, and a communication unit for communicating with other ECUs. It controls the onboard equipment by reading and executing control programs stored in the storage unit. Furthermore, the vehicle is also equipped with a communication device with wireless communication capabilities, enabling communication with a program provider connected to an external network. This program provider downloads (receives) the ECU's control program from (or updates the ECU's control program) (see, for example, Patent Document 1).
[0004] Existing technical documents
[0005] Patent documents
[0006] Patent Document 1: Japanese Patent Application Publication No. 2017-97851 Summary of the Invention
[0007] One aspect of this disclosure is an in-vehicle device comprising a control unit that acquires an additional program sent from an external server outside the vehicle and executes processing for applying the additional program to an in-vehicle ECU mounted on the vehicle. The control unit acquires information about a function configuration target ECU, which is an in-vehicle ECU among a plurality of in-vehicle ECUs mounted on the vehicle, determined based on determinations of necessary resource conditions and function configuration conditions. The control unit relays the additional program acquired from the external server to the determined function configuration target ECU based on the acquired information. Attached Figure Description
[0008] Figure 1 This is a schematic diagram illustrating the structure of a vehicle-mounted system including the vehicle-mounted device of Embodiment 1.
[0009] Figure 2 This is a block diagram illustrating the physical structure of an onboard device.
[0010] Figure 3This is a flowchart illustrating the processing (main flow) of the control unit of the vehicle-mounted device.
[0011] Figure 4 This is a flowchart illustrating the processing (function configuration determination) of the control unit of an onboard device.
[0012] Figure 5 This is a flowchart illustrating the processing (function configuration resource condition determination) of the control unit of an on-board device.
[0013] Figure 6 This is a flowchart illustrating the processing (function configuration target ECU determination) of the control unit of an on-board device.
[0014] Figure 7 This is an explanatory diagram illustrating matters related to system evaluation values (system standard information, weight coefficients, etc.).
[0015] Figure 8 This is an explanatory diagram illustrating the necessary resources for the functionality of an object.
[0016] Figure 9 This is an explanatory diagram illustrating resource information related to candidate ECUs.
[0017] Figure 10 This is an explanatory diagram illustrating matters related to the evaluation value of the functionality of an object.
[0018] Figure 11 This is an explanatory diagram illustrating matters related to evaluating information accessed via signals.
[0019] Figure 12 This is an explanatory diagram illustrating matters related to the configuration information of the evaluation function.
[0020] Figure 13 This is an explanatory diagram illustrating information about the structure of an in-vehicle network.
[0021] Figure 14 This is a flowchart illustrating the processing of the control unit of the vehicle-mounted device in Embodiment 2 (simulated by an external server). Detailed Implementation
[0022] [The problem this disclosure aims to solve]
[0023] The communication device (relay device) in Patent Document 1 does not consider efficiently identifying the ECU when applying additional programs obtained from an external server to any ECU installed in the vehicle.
[0024] The purpose of this disclosure is to provide an in-vehicle device, etc., that can efficiently identify any ECU installed in a vehicle when an additional program obtained from an external server is applied to any ECU installed in the vehicle.
[0025] [The Effects of This Disclosure]
[0026] According to one aspect of this disclosure, an in-vehicle device or the like can be provided that can efficiently identify any ECU installed in a vehicle when an additional program obtained from an external server is applied to any ECU installed in the vehicle.
[0027] [Description of embodiments disclosed herein]
[0028] First, embodiments of this disclosure are listed and described. Furthermore, at least a portion of the embodiments described below can be combined in any way.
[0029] (1) An in-vehicle device according to one aspect of the present disclosure includes a control unit that acquires an additional program sent from an external server outside the vehicle and executes processing for applying the additional program to an in-vehicle ECU mounted on the vehicle, wherein the control unit acquires information about a function configuration target ECU, the function configuration target ECU being an in-vehicle ECU among a plurality of in-vehicle ECUs mounted on the vehicle, determined based on a determination result regarding necessary resource conditions and function configuration conditions, and the control unit relays the additional program acquired from the external server to the determined function configuration target ECU based on the acquired information.
[0030] In this aspect, the vehicle-mounted device is communicatively connected to an external server, such as an OTA (Over-The-Air) server, located outside the vehicle, via a wireless external communication device. The external server stores additional or updated programs for various vehicle-mounted ECUs (ECUs) installed in the vehicle. By sending these additional programs to the vehicle (vehicle-mounted device), software functions are added to the vehicle. When the control unit of the vehicle-mounted device applies the additional program obtained from the external server to one of the multiple vehicle-mounted ECUs installed in the vehicle, it obtains necessary resource conditions and functional configuration conditions—conditions necessary for the application of the additional program. The control unit of the vehicle-mounted device can obtain these necessary resource conditions and functional configuration conditions from the external server. Based on the necessary resource conditions and functional configuration conditions obtained from the external server, the control unit of the vehicle-mounted device determines the functional configuration target ECU for which the additional program is applied. The vehicle-mounted ECU determined as the functional configuration target ECU corresponds to the vehicle-mounted ECU that is the configuration target for the software functions implemented by the additional program (the vehicle-mounted ECU that becomes the functional configuration target). Alternatively, the control unit of the vehicle-mounted device can determine the target ECU for its function configuration by obtaining information from an external server regarding the target ECU (the vehicle-mounted ECU that becomes the target function configuration) determined based on the determination results of necessary resource conditions and function configuration conditions. When determining whether the necessary resource conditions and function configuration conditions required for executing an additional program are met or not, the control unit of the vehicle-mounted device can perform not only individual simulations of each vehicle-mounted ECU but also communication simulations on the vehicle's in-vehicle network. Based on these necessary resource conditions and function configuration conditions required for executing the additional program, the control unit of the vehicle-mounted device relays the additional program obtained from the external server to the determined target ECU for its function configuration. Therefore, when sending additional programs from an external server (in the case of OTA), the appropriate configuration target for the software functions implemented by the additional program can be efficiently determined. By appropriately configuring the software functions, sufficient hardware resources (mainly the resources determined in the necessary resource conditions) for each of the multiple vehicle-mounted ECUs installed in the vehicle can be adequately ensured, and room for further software function additions can be guaranteed. Furthermore, by properly configuring this software functionality, it is possible to prevent a decrease in the responsiveness of each of these multiple vehicle ECUs, including existing functions. It also reduces the risk of resource shortages caused by the localization of functions to a single vehicle ECU.
[0031] (2) In an in-vehicle device of one aspect of this disclosure, the determination of the necessary resource conditions and the functional configuration conditions is performed by the external server, the control unit outputs vehicle information, including information about the resources of each of the multiple in-vehicle ECUs, to the external server, and the control unit obtains from the external server information about the functional configuration target ECU determined by the external server based on the vehicle information and the necessary resource conditions and the functional configuration conditions in the additional program.
[0032] In this aspect, the determination of necessary resource conditions and functional configuration conditions is performed by an external server. The control unit of the vehicle-mounted device outputs vehicle information, including information about the resources of each of the multiple vehicle-mounted ECUs, to the external server as necessary information for making this determination. Information about the resources of each of the multiple vehicle-mounted ECUs includes, for example, the CPU model, CPU operating frequency, memory model, memory storage capacity and free capacity, the type of program being executed (software part number, software function), the type of OS (operating system) installed, the presence or absence of a virtual environment (VM), and the physical layer protocol in the installed communication unit. Furthermore, as vehicle information, the control unit of the vehicle-mounted device can also output information about the connection configuration (network topology information) of these vehicle-mounted ECUs in the vehicle network to the external server. The external server obtains the vehicle information sent from the vehicle-mounted device and, based on this vehicle information and the necessary resource conditions and functional configuration conditions for the additional program, performs simulation of each individual vehicle-mounted ECU and communication simulation on the vehicle network. Based on the simulation results, the external server identifies the target ECU with the necessary resource and functional configuration conditions and sends information about the target ECU to the vehicle-mounted device. The control unit of the vehicle-mounted device, based on the information about the target ECU obtained from the external server, sends (relay) additional programs to the target ECU. Thus, when performing simulation processing to determine the necessary resource and functional configuration conditions, using an external server, such as a cloud server, reduces the computational load on the control unit of the vehicle-mounted device, preventing the hardware resources required by the control unit from becoming excessive.
[0033] (3) In an in-vehicle device of one aspect of the present disclosure, the control unit obtains from the external server the necessary resource conditions and the functional configuration conditions necessary for the in-vehicle ECU or the vehicle when executing the additional program. The control unit extracts one or more in-vehicle ECUs that have the necessary resource conditions as candidate ECUs. The control unit determines the candidate ECU that has the functional configuration conditions from the extracted candidate ECUs as the functional configuration target ECU.
[0034] In this aspect, when the control unit of the vehicle-mounted device obtains an additional program from an external server, it also obtains information (condition information) from the external server regarding the necessary resource conditions and functional configuration conditions required in the vehicle-mounted ECU or vehicle when executing the additional program. From the obtained necessary resource conditions and functional configuration conditions, the control unit of the vehicle-mounted device first uses the necessary resource conditions, which are the main information about hardware resources in the vehicle-mounted ECU, to extract vehicle-mounted ECUs that meet the necessary resource conditions as candidate ECUs. The control unit of the vehicle-mounted device can determine whether the necessary resource conditions are met or not for all vehicle-mounted ECUs installed in the vehicle, extract one or more vehicle-mounted ECUs that meet the necessary resource conditions as candidate ECUs, and generate a primary list of configuration target candidates consisting of these extracted candidate ECUs. This primary list of configuration target candidates can be stored in the storage unit of the vehicle-mounted device in the form of a list of candidate ECUs, in the order in which they are determined to meet the necessary resource conditions. The control unit of the vehicle-mounted device uses a candidate list of configuration targets, which includes one or more candidate ECUs. It sequentially determines whether these candidate ECUs meet or do not meet the functional configuration conditions, and identifies the candidate ECUs that meet the functional configuration conditions (vehicle ECUs with the necessary resource conditions) as the functional configuration target ECUs. In this way, by first defining the necessary resource conditions related to the hardware resources required for executing the additional program on the vehicle-mounted ECU, the range of vehicle-mounted ECUs that can be judged for functional configuration conditions can be narrowed down by extracting candidate ECUs. Therefore, in the determination of functional configuration conditions that require simulation and have a relatively high computational load, since the number of vehicle-mounted ECUs that can be judged can be reduced, the vehicle-mounted ECU can be efficiently identified when the additional program is applied to any vehicle-mounted ECU equipped in the vehicle.
[0035] (4) In an in-vehicle device of one aspect of this disclosure, the necessary resource conditions include at least one of the storage capacity, CPU model and operating frequency of the in-vehicle ECU.
[0036] In this aspect, the necessary resource conditions for the on-board ECU to execute the additional program include at least one of the following: storage capacity, CPU model, and operating frequency of the on-board ECU. That is, these necessary resource conditions are mainly equivalent to conditions related to the hardware resources in the on-board ECU. These necessary resource conditions are not limited to the hardware resources of the on-board ECU itself, such as its CPU or memory. Necessary resource conditions may include, for example, the number of initialization execution steps, the number of periodic execution steps, or the control allowable delay time, that is, the execution time calculated by combining the on-board ECU's CPU operating clock, etc., when the on-board ECU executes the additional program, and the maximum allowable response time from the generation of sensor signals (receiving signals from various sensors) to the output of actuators (outputting control signals to the on-board load controlled by the on-board ECU). In this way, by defining the necessary resource conditions equivalent to the required hardware resource requirements for the target ECU of the function configuration (software function configuration), the range of on-board ECUs (candidate ECUs) that are related to the determination of the necessary conditions of the function configuration can be narrowed down, and the computational load required for the necessary conditions of the function configuration can be reduced.
[0037] (5) In an in-vehicle device of one aspect of this disclosure, the function configuration conditions include necessary function configuration conditions and sufficient function configuration conditions that impose more restrictions than the necessary function configuration conditions. The control unit determines whether there is a candidate ECU that meets the sufficient function configuration conditions among the extracted candidate ECUs. If there is a candidate ECU that meets the sufficient function configuration conditions, the control unit determines the candidate ECU that meets the sufficient function configuration conditions as the target ECU for function configuration. If there is no candidate ECU that meets the sufficient function configuration conditions, the control unit determines whether there is a candidate ECU that meets the necessary function configuration conditions.
[0038] In this aspect, the functional configuration conditions include necessary functional configuration conditions and sufficient functional configuration conditions that are more restrictive than the necessary functional configuration conditions. That is, each of the multiple condition items (configuration condition items) contains condition values based on both necessary and sufficient functional configuration conditions. Necessary and sufficient functional configuration conditions are analogous to necessary and sufficient conditions in logical operations. When represented using a Venn diagram, the range of sufficient functional configuration conditions can fall within the range defined by the necessary functional configuration conditions. For each candidate ECU extracted from one or more candidate ECUs, the control unit of the vehicle device first determines whether the candidate ECU possesses sufficient functional configuration conditions that are more restrictive. Then, when it is determined that a candidate ECU does not possess sufficient functional configuration conditions, the control unit of the vehicle device determines whether the candidate ECU possesses necessary functional configuration conditions that are more lenient than sufficient functional configuration conditions. Thus, if a candidate ECU possesses sufficient functional configuration conditions, the control unit of the vehicle device identifies the candidate ECU with sufficient functional configuration conditions as the target ECU for functional configuration; if no candidate ECU possesses sufficient functional configuration conditions, it determines whether a candidate ECU possesses necessary functional configuration conditions. In this way, by performing a two-stage determination based on the necessary conditions and sufficient conditions for functional configuration, the target ECU for functional configuration can be determined efficiently.
[0039] (6) In an in-vehicle device of one aspect of the present disclosure, when the extracted candidate ECUs are multiple, the control unit sequentially determines whether the multiple candidate ECUs have the functional configuration sufficient conditions. When a candidate ECU is determined to have the functional configuration sufficient conditions, the control unit interrupts the determination process of the functional configuration sufficient conditions and does not perform the determination process on the undetermined candidate ECUs that are in the order after the candidate ECU.
[0040] In this aspect, the control unit of the vehicle-mounted device uses a primary list of candidate ECUs, which lists multiple candidate ECUs in the extracted order, to sequentially determine whether each candidate ECU in the primary list meets the functional configuration sufficiency conditions. When any candidate ECU is determined to meet the functional configuration sufficiency conditions, the control unit of the vehicle-mounted device interrupts the determination process for the functional configuration sufficiency conditions and does not process the determination of any candidate ECUs that are listed after that candidate ECU. That is, the control unit of the vehicle-mounted device determines the functional configuration sufficiency conditions sequentially according to the listing order in the primary list of candidate ECUs, and when any candidate ECU is determined to meet the functional configuration sufficiency conditions, that candidate ECU is designated as the functional configuration target ECU. Then, the control unit of the vehicle-mounted device does not process the determination of any candidate ECUs that are listed after the determined functional configuration target ECU (candidate ECUs that meet the functional configuration sufficiency conditions) and interrupts (ends) the determination process for the functional configuration sufficiency conditions. Therefore, it is possible to reduce the processing load related to determining the functional configuration conditions that require simulation and have a relatively high computational load, reduce the processing time required to determine the target ECU for the functional configuration, and suppress the increase in the computation time of the control unit of the vehicle device.
[0041] (7) In an in-vehicle device of one aspect of the present disclosure, the functional configuration conditions include multiple configuration condition items, the control unit extracts candidate ECUs that meet the necessary conditions for the functional configuration as second candidate ECUs, the control unit calculates the satisfaction rate of the configuration condition items in each of the second candidate ECUs, and the control unit determines the functional configuration target ECU based on the satisfaction rate in each of the second candidate ECUs.
[0042] In this aspect, when no candidate ECU meets the sufficient functional configuration conditions, the control unit of the vehicle device determines the target ECU for functional configuration from among the candidate ECUs that meet the necessary functional configuration conditions, which are more lenient than the sufficient functional configuration conditions. At this time, the control unit of the vehicle device can extract the candidate ECUs that meet the necessary functional configuration conditions as second candidate ECUs and generate a secondary list of target configuration candidates consisting of one or more extracted second candidate ECUs. This secondary list of target configuration candidates can be stored in the storage unit of the vehicle device in the form of a list listing the second candidate ECUs, in the order in which they are determined to meet the necessary functional configuration conditions. For each second candidate ECU listed in the secondary list of target configuration candidates, the control unit of the vehicle device calculates the satisfaction rate of each of the multiple configuration condition items included in the functional configuration conditions. The satisfaction rate can be derived from the evaluation value (evaluation value in each configuration condition item) derived from the simulation results when applying additional procedures to the second candidate ECU of the target, and the condition value (necessary condition value) and the condition value (sufficient condition value) in the necessary conditions for functional configuration of the configuration condition item: "Satisfaction rate = 1 - {(evaluation value - sufficient condition value) / (necessary condition value - sufficient condition value)}". However, when the evaluation value is below the sufficient condition value (evaluation value ≤ sufficient condition value), the satisfaction rate is 1.0. Furthermore, when the evaluation value is above the necessary condition value (evaluation value ≥ necessary condition value), the satisfaction rate is 0.0. The control unit of the vehicle device can efficiently determine the functional configuration target ECU from the comprehensive viewpoint of these multiple configuration condition items by using the satisfaction rate of each configuration condition item calculated from one or more extracted second candidate ECUs (second candidate ECUs listed in the secondary list of configuration target candidates).
[0043] (8) In an in-vehicle device of one aspect of the present disclosure, each of the configuration condition items is associated with a weight coefficient corresponding to its importance, and the control unit calculates the sum of the values obtained by multiplying the satisfaction rate of each of the configuration condition items by the weight coefficient in each of the second candidate ECUs, and the control unit determines the second candidate ECU with the largest sum as the functional configuration target ECU.
[0044] In this aspect, each configuration condition item is associated with a weighting coefficient corresponding to its importance when the vehicle performs software functions by executing additional programs. That is, a weighting coefficient is set (assigned) to the name of each configuration condition item (configuration condition item name), which uniquely represents each configuration condition item. The control unit of the vehicle device calculates the sum of the values obtained by multiplying each satisfaction rate derived from simulation results, etc., by the corresponding weighting coefficient in each of the second candidate ECUs (Σ(satisfaction rate × weighting coefficient)), and determines the second candidate ECU with the largest sum (MaxΣ(satisfaction rate × weighting coefficient)) as the function configuration target ECU. As a result, the importance of multiple configuration condition items can be considered to determine the function configuration target ECU, and the software functions implemented by the additional programs can be appropriately configured (functionally configured).
[0045] (9) In an in-vehicle device of one aspect of the present disclosure, the functional configuration conditions include at least one of the following: memory usage rate, CPU usage rate, allowable latency time, maximum startup time, bus load rate in the in-vehicle network of the vehicle, and relay latency time.
[0046] In this aspect, the configuration condition items in the functional configuration conditions (necessary conditions and sufficient conditions for functional configuration) include at least one of the following: memory usage rate, CPU usage rate, allowable latency time, maximum startup time, bus load rate in the vehicle's in-vehicle network, and relay latency time. These are equivalent to items representing the overall system evaluation value of the vehicle when the additional program is applied to the in-vehicle ECU. Thus, since the functional configuration conditions, as configuration condition items, include not only the evaluation value based on the individual performance of the in-vehicle ECU but also the overall system evaluation value of the vehicle, such as the communication load in the in-vehicle network, it is possible to achieve functional configuration of software that considers the overall optimization of the in-vehicle system.
[0047] (10) A procedure of one aspect of the present disclosure is used to cause a computer to perform the following processing, wherein the computer obtains an additional program sent from an external server outside the vehicle and performs processing for applying the additional program to an on-board ECU mounted on the vehicle: obtaining information about a function configuration target ECU, the function configuration target ECU being an on-board ECU among a plurality of on-board ECUs mounted on the vehicle, determined based on a determination result regarding necessary resource conditions and function configuration conditions, and relaying the additional program obtained from the external server to the function configuration target ECU.
[0048] In this respect, a program can be provided that enables a computer to perform processing as an in-vehicle device, which efficiently identifies an ECU when an additional program obtained from an external server is applied to any ECU mounted in the vehicle.
[0049] (11) An information processing method of one aspect of the present disclosure is used to cause a computer to perform the following processing, wherein the computer obtains an additional program sent from an external server outside the vehicle and performs processing for applying the additional program to an on-board ECU mounted on the vehicle: obtaining information about a functional configuration target ECU, the functional configuration target ECU being an on-board ECU among a plurality of on-board ECUs mounted on the vehicle, determined based on a determination result regarding necessary resource conditions and functional configuration conditions, and relaying the additional program obtained from the external server to the functional configuration target ECU.
[0050] In this respect, an information processing method can be provided that enables a computer to perform processing as an in-vehicle device, which efficiently identifies an ECU when additional programs obtained from an external server are applied to any ECU mounted in the vehicle.
[0051] [Detailed Description of Embodiments of This Disclosure]
[0052] This disclosure will be specifically described based on the accompanying drawings illustrating embodiments thereof. Hereinafter, the vehicle-mounted device 2 according to embodiments of this disclosure will be described with reference to the drawings. Furthermore, this 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.
[0053] (Implementation Method 1)
[0054] The embodiments will now be described with reference to the accompanying drawings. Figure 1 This is a schematic diagram illustrating the structure of a vehicle-mounted system including the vehicle-mounted device of Embodiment 1. Figure 2 This is a block diagram illustrating the physical structure of an in-vehicle device. The in-vehicle system S includes an external communication device 1 and an in-vehicle device 2 mounted on the vehicle C, which sends additional programs (OTA modules) obtained from an external server SV1 (program providing device, OTA server) connected via an external network N to the in-vehicle ECU3 (Electronic Control Unit) mounted on the vehicle C.
[0055] The external server SV1 is a computer, such as a server, connected to an external network N, such as the Internet or a public bus network. It has storage units such as RAM (Random Access Memory), ROM (Read Only Memory), or a hard disk, and functions as an external program provider. The storage unit of the external server SV1 contains programs or data created by the manufacturer of the onboard ECU3 (ECU3) for controlling that ECU3. This program or data is sent to the vehicle C as an add-on or update program to add or update the program or data of the onboard ECU3 installed in the vehicle C, thereby adding software functionality to the vehicle C. This external server SV1 (program provider) is also known as an OTA (Over-The-Air) server.
[0056] The vehicle-mounted device 2 functions as an OTA (Over-The-Air) host. This OTA host sends additional programs obtained from the external server SV1 to the vehicle-mounted ECU 3, which is the target application, and sends an activation instruction to apply the sent additional programs to the vehicle-mounted ECU 3. When determining the vehicle-mounted ECU 3 as the target application for the additional programs, the vehicle-mounted device 2, acting as the OTA host, considers the suitability of configuring software functions using the additional programs and identifies the vehicle-mounted ECU 3 as the target ECU for function configuration.
[0057] The following description uses program code containing control statements for execution by the vehicle ECU3 and an external file containing data referenced when executing the program code. When sending additional programs, this program code and the external file containing the data are sent from the external server SV1 as, for example, an encrypted archive file. The external server SV1 may also generate a package (OTA module) containing the additional program when sending it, and send the generated package (OTA module) to the vehicle C. The package (OTA module) may, for example, contain: information about the program addition (software function configuration), i.e., package information (activity information, OTA event), the additional program as the object of software function configuration, and various evaluation conditions (necessary resource conditions, function configuration conditions) for determining the software function configuration.
[0058] Vehicle C is equipped with an external communication device 1, an on-board device 2, and multiple on-board ECUs 3 for controlling various on-board devices. The external communication device 1 and the on-board device 2 are connected in a communicable manner via a wiring harness, such as a serial cable. The on-board device 2 and the on-board ECUs 3 are connected in a communicable manner via an on-board network 4 that supports communication protocols such as CAN (Control Area Network) or Ethernet (registered trademark).
[0059] The external communication device 1 includes an external communication unit (not shown) and an input / output interface for communicating with the onboard device 2. The external communication unit is a communication device used for wireless communication using mobile communication protocols such as LTE (registered trademark), 4G, 5G, and WiFi (registered trademark), and transmits and receives data with an external server SV1 via an antenna 11 connected to the external communication unit. Communication between the external communication device 1 and the external server SV1 is conducted, for example, via an external network N such as a public bus network or the Internet.
[0060] The input / output interface of the external communication device 1 is a communication interface used for serial communication with the vehicle-mounted device 2, for example. The external communication device 1 and the vehicle-mounted device 2 communicate with each other via a wiring harness such as a serial cable connected between the input / output interfaces. In this embodiment, the external communication device 1 is a device different from the vehicle-mounted device 2, and these devices are connected in a communicative manner via the input / output interface, but this is not a limitation. The external communication device 1 may also be integrated into the vehicle-mounted device 2 as a component of the vehicle-mounted device 2. Alternatively, the external communication device 1 and the vehicle-mounted device 2 may be connected via a vehicle network 4 such as CAN.
[0061] The vehicle-mounted device 2 includes a control unit 20, a storage unit 23, an input / output interface 21, and an in-vehicle communication unit 22. The vehicle-mounted device 2 is configured to: obtain an over-the-air (OTA) module from an external communication device 1, which receives the OTA module from an external server SV1 via wireless communication; and send the OTA module to the vehicle-mounted ECU 3 (the target ECU for function configuration) determined as the target ECU via the vehicle network 4. That is, the vehicle-mounted device 2 functions as an OTA host (update device) controlling the determination of the target ECU for function configuration and the addition of software function configuration to that target ECU. Furthermore, the determination of the target ECU for function configuration is not limited to being performed by the vehicle-mounted device 2; the external server SV1 can also use vehicle information sent from the vehicle-mounted device 2 to determine the target ECU for function configuration.
[0062] The vehicle-mounted device 2 is, for example, a bus (segment) for multiple systems such as the vehicle-mounted ECU 3 of the control system, the vehicle-mounted ECU 3 of the safety system, and the vehicle-mounted ECU 3 of the body system, and serves as a gateway (vehicle-mounted relay device) that relays communication between these vehicle-mounted ECU 3s. That is, the vehicle-mounted device 2 is connected to communication lines 41 that constitute these multiple buses (segments), and the multiple communication lines 41 (segments) converged by the vehicle-mounted device 2 form the vehicle-mounted network 4. The vehicle-mounted device 2 functions as a CAN gateway in CAN protocol relays and as a Layer 2 switch or Layer 3 switch in TCP / IP protocol relays. In addition to communication-related relays, the vehicle-mounted device 2 can also be a PLB (Power Lanbox), which functions as a power distribution device that distributes and relays power output from power supply devices such as secondary batteries and supplies power to vehicle-mounted equipment such as actuators connected to its own device. Alternatively, the vehicle-mounted device 2 can also be configured as a functional unit of the body ECU that controls the entire vehicle C. Alternatively, the on-board unit 2 may be composed of a central control unit such as a vehicle computer, which is an integrated ECU that performs overall control of the vehicle C.
[0063] The control unit 20 is composed of a CPU (Central Processing Unit) or MPU (Micro Processing Unit), etc., and performs various control and calculation processes by reading and executing the control program P (program product) and data pre-stored in the storage unit 23.
[0064] The storage unit 23 is composed of volatile storage elements such as RAM (Random Access Memory) or non-volatile storage elements such as ROM (Read Only Memory), EEPROM (Electrically Erasable Programmable ROM), or flash memory. The storage unit 23 stores pre-stored control program P and vehicle information (described later) as reference data during processing. Furthermore, the storage unit 23 stores various data obtained by the control unit 20 from the external server SV1. Additionally, the storage unit 23 stores various intermediate data generated by the control unit 20 during various arithmetic and simulation processing operations. The control program P (program product) stored in the storage unit 23 can be a program product that stores control program P (program product) read from a recording medium M readable from the vehicle-mounted device 2. Alternatively, it can be a program product that downloads control program P from an external computer (not shown) connected to a communication network (not shown) and stores it in the storage unit.
[0065] The input / output interface 21, like the input / output interface of the external communication device 1, is a communication interface for example, used for serial communication. The vehicle-mounted device 2 is communicatively connected to the external communication device 1, a display device such as a monitor, or an ignition switch for starting or stopping the vehicle C via the input / output interface.
[0066] The in-vehicle communication unit 22 is an input / output interface that uses communication protocols such as CAN or Ethernet (registered trademark). The control unit 20 communicates with in-vehicle devices such as the in-vehicle ECU 3 or other relay devices connected to the in-vehicle network 4 via the in-vehicle communication unit 22. Multiple in-vehicle communication units 22 are provided (three in this embodiment), and each in-vehicle communication unit 22 is connected to a communication line 41 (segment, CAN bus) that constitutes the in-vehicle network 4.
[0067] Like the vehicle-mounted device 2, the vehicle-mounted ECU 3 includes a control unit (CPU), a storage unit, and an in-vehicle communication unit. The storage unit is composed of volatile storage elements such as RAM or non-volatile storage elements such as ROM, EEPROM, or flash memory, and stores the program or data of the vehicle-mounted ECU 3. This program or data is an object added from a program sent from a program providing device and relayed by the vehicle-mounted device 2. The in-vehicle communication unit of the vehicle-mounted ECU 3, like that of the vehicle-mounted device 2, is composed of, for example, a CAN transceiver or an Ethernet PHY unit, and communicates with the vehicle-mounted device 2 via this in-vehicle communication unit.
[0068] Figure 3 This is a flowchart illustrating the processing (main flow) of the control unit 20 of the vehicle-mounted device 2. Figure 4 This is a flowchart illustrating the processing (function configuration determination) of the control unit 20 of the vehicle-mounted device 2. Figure 5 This is a flowchart illustrating the processing (function configuration resource condition determination) of the control unit 20 of the vehicle-mounted device 2. Figure 6 This is a flowchart illustrating the processing (function configuration target ECU determination) of the control unit 20 of the vehicle-mounted device 2. The control unit 20 of the vehicle-mounted device 2 executes as the main routine. Figure 3 When processing, you can Figures 4 to 6 The subroutines are executed as processes of the main routine, etc. The control unit 20 of the vehicle device 2 stably executes the following processes, for example, when the vehicle C is in a stopped state (e.g., the ignition switch is off).
[0069] Figure 7 This is an explanatory diagram illustrating matters related to system evaluation values (system standard information, weight coefficients, etc.). Figure 8 This is an explanatory diagram illustrating the necessary resources for the functionality of an object. Figure 9 This is an explanatory diagram illustrating resource information related to candidate ECUs. Figure 10 This is an explanatory diagram illustrating matters related to the evaluation value of the functionality of an object. Figure 11 This is an explanatory diagram illustrating matters related to evaluating information accessed via signals. Figure 12 This is an explanatory diagram illustrating matters related to the configuration information of the evaluation function. Figure 13 This is an explanatory diagram illustrating information regarding the configuration of the vehicle network. The control unit 20 of the vehicle device 2 will... Figures 8 to 13 Various types of information defined in the specification are stored in the storage unit 23. When the control unit 20 of the vehicle-mounted device 2 performs a series of processes in this embodiment, it can store these various types of information in the storage unit 23 as intermediate data in various operations.
[0070] The control unit 20 of the vehicle-mounted device 2 detects an OTA start event (S1). The control unit 20 of the vehicle-mounted device 2 communicates periodically or stably with an external server SV1 (OTA server) and detects that an OTA start event has occurred by obtaining, for example, activity information about an add-on program or update program used to execute new software functions, i.e., information about the OTA start event.
[0071] The control unit 20 of the vehicle-mounted device 2 determines the function configuration of the OTA module as an add-on program (S2). Triggered by detecting an OTA start event, the control unit 20 of the vehicle-mounted device 2 begins processing for configuring the function of the OTA module (add-on program, etc.) that is the target of the OTA start event. The control unit 20 of the vehicle-mounted device 2 performs the processing of S2. Figure 4 The series of processes shown.
[0072] The control unit 20 of the vehicle-mounted device 2 acquires vehicle information (S201). Information about all vehicle-mounted ECUs 3 installed in the vehicle C is periodically or stably collected by the control unit 20 of the vehicle-mounted device 2 and stored as vehicle information in the storage unit 23. This vehicle information includes: the CPU model, CPU operating frequency, memory model, memory storage capacity and free capacity, type of program being executed (software part number, software function), type of installed OS (operating system), presence or absence of a virtual environment (VM), and physical layer protocol of the installed communication unit, etc. This information about the vehicle-mounted ECUs 3 can be, for example, as follows: Figure 9 The resource information table for the candidate ECUs shown is stored in the storage unit 23 in tabular form. The resource information table for the candidate ECUs, as a management item, includes, for example, the ECU name, VM name, amount of ROM, amount of free ROM, CPU, operating frequency, amount of RAM, and amount of free RAM, and stores the corresponding resource information in the vehicle ECU 3.
[0073] Vehicle information may also include evaluation signal access information, which includes information about the type (name) and transmission cycle of signals output by each onboard ECU3. Evaluation signal access information may include, for example,... Figure 11 The evaluation signal access information table shown is stored in the storage unit 23 in tabular form. The evaluation signal access information table, as a management item, includes, for example, signal name, transmission cycle, and ECU name, and is defined in a matrix structure. In the evaluation signal access information table, for each defined signal name (signal A, signal B, obstacle approach information, vehicle C speed, brake output indication, instrument display indication, sound output indication), the processing mode (R: input, W: output) executed by the on-board ECU 3 (ECU name: control 001, control 002, automatic braking control, sonar ECU, instrument control, audio control, brake control) is stored.
[0074] Vehicle information may also include evaluation function configuration information, which is information about the functions (software functions) performed by each on-board ECU3 installed in vehicle C. Evaluation function configuration information may include, for example,... Figure 12 The evaluation function configuration information table shown is stored in the storage unit 23 in tabular form. As a management item, the evaluation function configuration information table includes, for example, the ECU name that uniquely identifies the vehicle ECU 3, the VM name that indicates the virtual environment running on the vehicle ECU 3, and the name of the function performed by the vehicle ECU 3.
[0075] Vehicle information may also include in-vehicle network configuration information, such as information about the in-vehicle ECU 3 connected to the in-vehicle network 4. In-vehicle network configuration information may include, for example,... Figure 13 The vehicle network configuration information is stored in the storage unit 23 in tabular form, as shown in the vehicle network configuration information table. The vehicle network configuration information table, as a management item, includes, for example, the parent bus name uniquely representing the communication line 41 to which the vehicle ECU 3 is connected, the name of the connected vehicle ECU 3 (ECU name), the name of the virtual environment (VM name) running on that vehicle ECU 3, and the sub-bus name representing the communication line 41 configured under the parent bus name through the cascading structure in the communication line 41. As described later, the control unit 20 of the vehicle device 2 uses these evaluation signal access information, evaluation function configuration information, and vehicle network configuration information to perform communication simulations on the case where software functions are configured on any vehicle ECU (candidate ECU) (with an additional program applied), and derives evaluation values such as the CAN bus load rate (network load rate) and CAN relay delay (communication delay) in the vehicle network 4.
[0076] The control unit 20 of the vehicle-mounted device 2 obtains information about the necessary resources for the target function, including the necessary resource conditions and function configuration conditions in the additional program (S202). The control unit 20 of the vehicle-mounted device 2 obtains information about the necessary resources for the target function, including the necessary resource conditions and function configuration conditions, in the additional program that is the target of software function configuration from an external server SV1 (OTA server). For the vehicle-mounted ECU 3 performing software function configuration, the conditions (necessary resource conditions) related to hardware resources such as CPU or memory are, for example, provided by... Figure 8 The required resource table for the object function is shown below. This required resource table, as a management item, includes: module name (the name of the OTA module: for example, automatic braking control), required ROM amount, number of initialization execution steps, number of periodic execution steps, corresponding CPU, required RAM amount, and control allowable delay time.
[0077] The initialization execution step count and the periodic execution step count are combined with the CPU operating clock (frequency) of the configured target vehicle ECU3 to calculate the execution time. If modules corresponding to multiple CPU types are prepared in advance, all can be listed. When the module is, for example, an executable image running on a virtual machine such as JAVA (registered trademark), a value indicating no CPU type restriction (ANY, etc.) can be recorded.
[0078] The control tolerance delay time represents the maximum permissible response time from the generation or reception of sensor signals acquired by the vehicle ECU3 for control purposes to the output of control signals to vehicle loads such as actuators directly connected to the vehicle ECU3. This control tolerance delay time (maximum permissible response time) can include a necessary condition value (e.g., 500ms or less) and a sufficient condition value (e.g., 200ms or less) that imposes more restrictions (more stringent requirements) on the condition than the necessary condition value. The control unit 20 of the vehicle device 2 can also, in this way, use two condition values—based on the sufficient condition value and the necessary condition value—to determine whether the conditions for the vehicle ECU3 are met under necessary resource conditions, such as the control tolerance delay time.
[0079] The control unit 20 of the vehicle-mounted device 2 extracts candidate ECUs that may become functional configuration targets (S203). Using vehicle information stored in the storage unit 23, the control unit 20 evaluates each of the necessary resource conditions (i.e., whether they are present or not) for all vehicle-mounted ECUs 3 mounted on the vehicle C, primarily defining the necessary resource conditions related to the hardware resources of the vehicle-mounted ECUs 3. The control unit 20 can determine whether certain conditions are present or not for evaluation items (static resource conditions) defined as single condition values, such as necessary ROM quantity, initialization execution steps, cycle execution steps, corresponding CPU, and necessary RAM quantity.
[0080] The control unit 20 of the vehicle-mounted device 2 uses vehicle information stored in the storage unit 23 to evaluate all vehicle-mounted ECUs 3 installed in the vehicle C. This is done by comparing the evaluation criteria for each ECU 3, including CPU model, CPU operating frequency, memory model, memory storage capacity and free capacity, type of program being executed (software part number, software function), type of operating system (OS), presence or absence of a virtual environment (VM), physical layer protocol of the installed communication unit, and necessary resource conditions. ECUs meeting all these evaluation criteria are added as candidate ECUs to the configuration target candidate list. By generating this configuration target candidate list, one or more vehicle-mounted ECUs (candidate ECUs) whose hardware resources can handle (meet the requirements) the software function configuration (application of additional programs) are included in the configuration target candidate list based on the necessary resource conditions evaluation criteria. The multiple vehicle-mounted ECUs (candidate ECUs) included in this configuration target candidate list can be listed, for example, in the order determined by the control unit 20 of the vehicle-mounted device 2, or in the order (ascending order, etc.) of the unique identifiers such as the ECU-ID that represent the vehicle-mounted ECU 3.
[0081] The control unit 20 of the vehicle-mounted device 2 sequentially selects candidate ECUs included in the configuration target candidate primary list (S204). The control unit 20 of the vehicle-mounted device 2 selects candidate ECUs included in the configuration target candidate primary list sequentially, for example, by referring to the configuration target candidate primary list generated and stored in the storage unit 23 from the beginning. The control unit 20 of the vehicle-mounted device 2 can distinguish between selected and unselected candidate ECUs by adding a flag value indicating selection to the configuration target candidate primary list for each sequentially selected candidate ECU.
[0082] The control unit 20 of the vehicle-mounted device 2 performs a determination of the necessary resource conditions for the selected candidate ECU (S205). The control unit 20 of the vehicle-mounted device 2 performs the processing in S205. Figure 5 (Functional Configuration Resource Condition Determination) shows a series of processes. Among the candidate ECUs included in the configuration target candidate list, when configuring software functions such as CPU model and operating frequency, volatile and non-volatile memory capacity and free capacity, virtual environment presence, physical layer protocol type, and installed OS type, the model or specification requirements (static resource conditions) for the vehicle ECU3 are met.
[0083] The control unit 20 of the vehicle-mounted device 2 further performs the following processing: when configuring the software function of the candidate ECU, it takes into account the memory area and CPU usage time used by various programs or applications already executed (applied) on the candidate ECU, and derives the evaluation values of various evaluation items (dynamic resource conditions) when executing additional programs.
[0084] When deriving the evaluation values for each of these evaluation items, the control unit 20 of the vehicle-mounted device 2 can model the hardware structure of the vehicle-mounted ECU 3 and perform simulation by executing additional and existing programs on this model. These 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 vehicle-mounted device 2 can also determine whether conditions related to the maximum control response time (control allowable delay time), which is an evaluation value, are met or not.
[0085] When determining whether the conditions for each of these evaluation items are met, the control unit 20 of the vehicle-mounted device 2 can use the condition value corresponding to the evaluation item. Based on this, the condition value can include a necessary condition value and a sufficient condition value that imposes more restrictions on the conditions than the necessary condition value. The control unit 20 of the vehicle-mounted device 2 can determine whether the evaluation value derived from simulation or the like is met or not, relative to the necessary condition value and the sufficient condition value, for each evaluation item.
[0086] The control unit 20 of the vehicle-mounted device 2 determines whether the memory usage rate condition among the necessary resource conditions is met (S2051). As a memory usage rate condition, the control unit 20 of the vehicle-mounted device 2 can, for example, perform a determination related to the usage rates of volatile memory (RAM) and non-volatile memory (ROM). The memory usage rate condition can be, for example, as follows: Figure 7 The information regarding system evaluation values, as shown, is stored in the storage unit 23 in tabular form. This information includes system standard information such as defining memory usage conditions.
[0087] System standard information is stored in tabular form (system standard information table). This table serves as a management item, including evaluation items, necessary conditions, and sufficient conditions, equivalent to functional configuration conditions. Evaluation items in the system standard information table (functional configuration conditions) include, for example, CAN bus load rate, CAN frame relay delay, ROM utilization, RAM utilization, maximum startup time, and maximum CPU utilization. Within each of these evaluation items, necessary conditions (functional configuration necessary conditions) and sufficient conditions (functional configuration sufficient conditions) that impose more restrictions (more stringent requirements) are defined.
[0088] In the aforementioned determination related to the usage rate of volatile memory (RAM) and non-volatile memory (ROM), the control unit 20 of the vehicle-mounted device 2 derives the memory usage rate when configuring software functions (applying additional programs) to the selected candidate ECU by referring to the system standard information table. The control unit 20 of the vehicle-mounted device 2 also obtains information about existing programs already applied to the candidate ECU by referring to vehicle information. Based on this, the control unit 20 of the vehicle-mounted device 2 can calculate the memory usage rate (ROM usage rate, RAM usage rate) when applying additional programs based on the memory usage and memory capacity of each program, or derive it using simulation or other methods.
[0089] The control unit 20 of the vehicle-mounted device 2 uses the exported memory usage rate (ROM usage rate, RAM usage rate) as an evaluation value and stores it in the aforementioned system evaluation value table, for example as... Figure 7 The system evaluation values shown are stored in the storage unit 23 for each candidate ECU. The control unit 20 of the vehicle device 2 can determine whether the derived evaluation values (ROM usage rate, RAM usage rate) are met or not using two condition values: sufficient condition value and necessary condition value.
[0090] If the memory utilization condition is met (S2051: Yes), the control unit 20 of the vehicle-mounted device 2 determines whether the maximum CPU utilization condition among the necessary resource conditions is met (S2052). If the evaluation values (ROM utilization, RAM utilization) derived for the candidate ECU meet the necessary condition values, the control unit 20 of the vehicle-mounted device 2 determines whether the candidate ECU meets the maximum CPU utilization condition. Regarding the maximum CPU utilization condition, sufficient conditions (functional configuration sufficient conditions) and necessary conditions (functional configuration necessary conditions) are also defined in the system standard information table.
[0091] The control unit 20 of the vehicle-mounted device 2, by referring to vehicle information, learns about the existing programs already applied to the candidate ECU. Based on this, it can calculate the maximum CPU utilization when applying additional programs, using factors such as CPU time slice values and operating frequencies for each program, or derive it using simulation. The control unit 20 of the vehicle-mounted device 2 uses the derived maximum CPU utilization as an evaluation value and stores it in the aforementioned system evaluation value table, for example, as... Figure 7 The information regarding the system evaluation value shown is stored in the storage unit 23 for each candidate ECU. The control unit 20 of the vehicle device 2 can determine whether the derived evaluation value (maximum CPU utilization) is met or not using two condition values: sufficient condition value and necessary condition value.
[0092] If the maximum CPU utilization condition is met (S2052: Yes), the control unit 20 of the vehicle device 2 determines whether the maximum startup time condition among the necessary resource conditions is met (S2053). If the evaluation value (maximum CPU utilization) derived for the candidate ECU meets the necessary condition value, the control unit 20 of the vehicle device 2 determines whether the candidate ECU meets the maximum startup time condition.
[0093] The control unit 20 of the vehicle-mounted device 2, by referring to vehicle information, learns about the existing programs already applied to the candidate ECU. Based on this, it can calculate the maximum startup time when applying additional programs based on the CPU time slice value and operating frequency used by each program, or derive it using simulation or the like. The control unit 20 of the vehicle-mounted device 2 uses the derived maximum startup time as an evaluation value and stores it in the aforementioned system evaluation value table, for example, as... Figure 7 The information regarding the system evaluation value shown is stored in the storage unit 23 for each candidate ECU. The control unit 20 of the vehicle device 2 can determine whether the derived evaluation value (maximum start-up time) is met or not using two condition values: sufficient condition value and necessary condition value.
[0094] When the maximum startup time condition is met (S2053: Yes), the control unit 20 of the vehicle-mounted device 2 assigns the selected candidate ECU the meaning that it has the necessary resource condition (True) (S2054). In this embodiment, when the candidate ECU has the maximum startup time condition, the candidate ECU will have all the conditions of memory utilization (ROM utilization, RAM utilization), maximum CPU utilization, and maximum startup time. That is, the candidate ECU listed in the configuration target candidate list has at least the necessary condition values among memory utilization (ROM utilization, RAM utilization), maximum CPU utilization, and maximum startup time, in addition to having the ROM availability, RAM availability, and CPU availability required as hardware resource requirements. The control unit 20 of the vehicle-mounted device 2 can, for example, use the judgment result information (object function availability evaluation value, system evaluation value) associated with the evaluation value and judgment result (sufficient availability, necessary availability) for various evaluation items for the candidate ECU. Figure 10 The table of object functionality evaluation values shown is stored in storage unit 23.
[0095] If the memory utilization condition is not met (S2051: No), the maximum CPU utilization condition is not met (S2052: No), or the maximum startup time condition is not met (S2053: No), the control unit 20 of the vehicle-mounted device 2 assigns the meaning of "not meeting the necessary resource conditions" (False) to the selected candidate ECU (S2055). For the selected candidate ECU, if any one of the necessary conditions—memory utilization, maximum CPU utilization, and maximum startup time—is not met, the control unit 20 of the vehicle-mounted device 2 assigns the meaning of "not meeting the necessary resource conditions" (False) to the candidate ECU and stores this meaning in the storage unit 23.
[0096] The control unit 20 of the vehicle-mounted device 2 determines whether the selected candidate ECU has the necessary resource conditions (S206). Based on the above determination result, the control unit 20 of the vehicle-mounted device 2, by referring to the determination result stored in the storage unit 23, determines whether the selected candidate ECU has at least the necessary condition value (True) in all 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 necessary resource conditions are not met (S206: No), the control unit 20 of the vehicle-mounted device 2 performs loop processing to execute S204 and subsequent processes again.
[0097] When the necessary resource conditions are met (S206: Yes), the control unit 20 of the vehicle device 2 calculates the system evaluation value by performing a communication simulation (S207). When the necessary resource conditions are met, the control unit 20 of the vehicle device 2 calculates the system evaluation value in the condition item (system evaluation item) of the function configuration conditions by performing a communication simulation under the operating environment of the selected candidate ECU and the candidate ECU being connected to the vehicle network 4.
[0098] As mentioned above, the condition items (system evaluation items) for functional configuration are as follows: Figure 7 As shown, the system evaluation values are stored in the storage unit 23 in tabular form. In the condition items (system evaluation items) of this function configuration condition, the evaluation values (memory utilization, maximum CPU utilization, maximum startup time condition) of the candidate ECU have been derived through the above processing. For other condition items (system evaluation items), such as CAN bus load rate and CAN frame relay delay, under the operating environment where the candidate ECU is connected to the vehicle network 4, the control unit 20 of the vehicle device 2 derives evaluation values, for example, by performing communication simulation.
[0099] When performing the communication simulation, the control unit 20 of the vehicle-mounted device 2 refers to various information included in the vehicle information (evaluation signal access information, evaluation function configuration information, and vehicle network configuration information). For example, the evaluation signal access information includes... Figure 11 The evaluation signal access information table shown is stored in storage unit 23. Evaluation function configuration information, for example, is... Figure 12 The evaluation function configuration information table shown is stored in storage unit 23. Vehicle network configuration information, for example, is... Figure 13 The table showing the vehicle network configuration information is stored in storage unit 23.
[0100] The control unit 20 of the vehicle-mounted device 2 uses this information (evaluation signal access information, evaluation function configuration information, and vehicle network configuration information) to generate a model corresponding to the state of the candidate ECU with software function configuration, and uses the model to perform communication simulation. Based on the results of the communication simulation, the control unit 20 of the vehicle-mounted device 2 derives evaluation values (system evaluation values) for the CAN bus load rate and CAN frame relay delay.
[0101] The control unit 20 of the vehicle-mounted device 2 can generate a model corresponding to the state in which the candidate ECU has been configured with software functions (additional programs have been applied) by reflecting (adding) the state in the evaluation signal access information, evaluation function configuration information, and vehicle network configuration information. At this time, the control unit 20 of the vehicle-mounted device 2 uses the network configuration of the vehicle C, the ID, period and size of the data sent by each vehicle-mounted ECU 3 or sensor, and the ID of the data required by each vehicle-mounted ECU 3 contained in these various information to perform communication simulation on the virtual vehicle network 4 (model). The control unit 20 of the vehicle-mounted device 2 calculates values such as the communication load of each communication line 41 (such as CAN bus) or the maximum delay time of each data by measuring the amount and frequency of data sent and received on the virtual vehicle network 4 (model) in the communication simulation.
[0102] The control unit 20 of the vehicle-mounted device 2 can calculate the ratio of the time of data transmission and reception to the total time of the communication simulation for each communication line 41 as the communication load rate, and calculate the average of the communication load rates of multiple communication lines 41 as the average load rate. For each piece of data transmitted and received in the virtual vehicle network 4 (model), the control unit 20 of the vehicle-mounted device 2 calculates the delay time from the moment the data is sent by the sending source vehicle-mounted ECU 3 to the moment the data is received by the receiving side vehicle-mounted ECU 3. The control unit 20 of the vehicle-mounted device 2 can calculate the delay time of all data transmitted and received in the communication simulation and obtain the maximum delay time as the maximum delay time.
[0103] When performing communication simulation, the control unit 20 of the vehicle-mounted device 2 can refer to the scenario information (use case database) stored in the storage unit 23. The scenario information can be stored in the storage unit 23 as a use case database (action database), which stores the correspondence between various actions performed in the vehicle C and the events that occur in these actions.
[0104] The control unit 20 of the vehicle-mounted device 2 uses scenario information (use case database) to input input data into the virtual vehicle-mounted network 4 (model) and obtains various output data from the virtual vehicle-mounted network 4 (model) based on the input data. Based on the scenario information, the control unit 20 manages the time in the communication simulation and repeatedly executes the input and output of data relative to the virtual vehicle-mounted network 4 (model) as time passes. The control unit 20 acquires information such as the internal state of the virtual vehicle-mounted network 4 (model) that changes as the scenario is executed, and stores the acquired information as an action log in the communication simulation, associated with the time point of information acquisition, in the storage unit 23.
[0105] When the control unit 20 of the vehicle-mounted device 2 generates a scenario for performing communication simulation based on scenario information (use case database), the scenario may include, for example, information for simulating all use cases stored in the use case database. The control unit 20 of the vehicle-mounted device 2 executes all events contained in the scenario, performing communication simulations for all use cases on the virtual vehicle network 4 (model). The action log output by performing the communication simulation may include information such as the output data of the virtual vehicle network 4 (model) or the internal status information such as the CPU utilization of the vehicle ECUs 3 contained in the virtual vehicle network 4 (model) for all steps contained in the scenario. This action log may include information such as the output data of the virtual vehicle network 4 (model) or the internal status information of all vehicle ECUs 3 contained in the virtual vehicle network 4 (model) for all steps contained in the scenario.
[0106] The control unit 20 of the vehicle-mounted device 2 calculates the load rate or communication latency of the vehicle network 4 based on the action log obtained as a result of the communication simulation. The control unit 20 of the vehicle-mounted device 2 can calculate the ratio of the time for data transmission and reception on each communication bus included in the virtual vehicle network 4 (model) to the total time of the communication simulation, and use the highest ratio or the average of multiple ratios among all communication buses as the load rate of the vehicle network 4. Alternatively, the control unit 20 of the vehicle-mounted device 2 can calculate the time (delay time) from when the data is sent from the source to when it is received at the destination for all data transmitted and received in the communication simulation, and use the maximum value or average of multiple delay times calculated for all data as the communication latency of the network. By performing the above-described communication simulation, the control unit 20 of the vehicle-mounted device 2 derives evaluation values (system) for various system evaluation items in the vehicle network 4, such as CAN bus load rate (maximum CAN bus load rate) and CAN frame relay delay (maximum CAN relay delay), as well as network load rate, communication latency, or traffic, and stores these values in the storage unit 23, for example, by storing them in a system evaluation value table for each candidate ECU.
[0107] The control unit 20 of the vehicle-mounted device 2 determines whether the system evaluation value meets the functional configuration sufficiency conditions (S208). For each evaluation value (system evaluation value) derived from the system evaluation items for the selected candidate ECU, the control unit 20 of the vehicle-mounted device 2 determines whether all the pre-set sufficiency conditions (functional configuration sufficiency conditions) for that evaluation item are met. Evaluation items judged in this process include, for example, memory utilization (ROM utilization, RAM utilization), maximum CPU utilization, maximum startup time, maximum control response time (control allowable delay time), maximum CAN bus load rate, and maximum CAN relay delay. The evaluation values (system evaluation values) of these evaluation items are derived through communication simulation, etc. The control unit 20 of the vehicle-mounted device 2 determines, for example, whether the system evaluation value of each system evaluation item meets the sufficiency condition value by referring to the necessary and sufficient conditions included in the system evaluation value table.
[0108] If the system evaluation value meets the sufficient conditions for functional configuration (S208: Yes), the control unit 20 of the vehicle device 2 determines the candidate ECU that meets the sufficient conditions for functional configuration as the target ECU for functional configuration (S2081). When the evaluation values (system evaluation values) of all system evaluation items in the selected candidate ECU meet the sufficient conditions (satisfy the sufficient condition values), the control unit 20 of the vehicle device 2 determines (determines) that candidate ECU as the target ECU for functional configuration. By determining (determining) it as the target ECU for functional configuration in this process, the control unit 20 of the vehicle device 2 ends the series of processes for determining the functional configuration of the OTA module. As a result, the control unit 20 of the vehicle device 2 interrupts the process of determining the functional configuration of the OTA module and does not perform the judgment process for all candidate ECUs included in the initial list of target candidates.
[0109] If the system evaluation value does not meet the sufficient conditions for functional configuration (S208: No), the control unit 20 of the vehicle device 2 determines whether the system evaluation value meets the necessary conditions for functional configuration (S209). When none of the evaluation values (system evaluation values) of the system evaluation items in the selected candidate ECU meet the sufficient conditions for any evaluation item, the control unit 20 of the vehicle device 2 determines whether the system evaluation value meets the necessary conditions for functional configuration for that candidate ECU.
[0110] If the system evaluation value meets the necessary conditions for functional configuration (S209: Yes), the control unit 20 of the vehicle-mounted device 2 adds the candidate ECU (second candidate ECU) to the secondary list of configuration target candidates (S210). When all evaluation values (system evaluation values) of the system evaluation items in the selected candidate ECU meet the necessary conditions (satisfy the necessary condition values), the control unit 20 of the vehicle-mounted device 2 determines the candidate ECU as the second candidate ECU and adds it to the secondary list of configuration target candidates. Thus, in the secondary list of configuration target candidates, the vehicle-mounted ECU 3 (second candidate ECU) that meets the necessary conditions (functional configuration necessary conditions) for all evaluation values (system evaluation values) of the system evaluation items is listed.
[0111] If the system evaluation value does not meet the necessary conditions for functional configuration (S209: No), or after executing S210, the control unit 20 of the vehicle-mounted device 2 determines whether the evaluation of all candidate ECUs has been completed (S211). If the system evaluation value does not meet the necessary conditions for functional configuration, or after executing the process of S210, the control unit 20 of the vehicle-mounted device 2 determines whether the evaluation of all candidate ECUs has been completed by referring to the configuration target candidate primary list, that is, whether there are any unevaluated candidate ECUs. The control unit 20 of the vehicle-mounted device 2 can identify unevaluated candidate ECUs by checking the flag values added to the configuration target candidate primary list indicating that they have been selected. If the evaluation of all candidate ECUs has not been completed (S211: No), the control unit 20 of the vehicle-mounted device 2 performs loop processing to execute the processing of S204 and thereafter again.
[0112] After evaluating all candidate ECUs (S211: Yes), the control unit 20 of the vehicle-mounted device 2 determines the functional configuration target ECU from the secondary list of configuration target candidates (S212). The control unit 20 of the vehicle-mounted device 2 performs the processing in S212. Figure 6 (The series of processes shown in the "Function Configuration Target ECU Determined")
[0113] The control unit 20 of the vehicle-mounted device 2 sequentially retrieves information about the second candidate ECU from the secondary list of configuration target candidates (S2121). For each second candidate ECU listed in the secondary list of configuration target candidates, the control unit 20 sequentially retrieves information about the second candidate ECU, for example, in the order of listing. For each second candidate ECU included in the secondary list of configuration target candidates, for example... Figure 7The system evaluation value table shown 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 weight coefficients. The control unit 20 of the vehicle device 2 obtains information about the second candidate ECU listed in the secondary list of configuration target candidates by referring to the system evaluation value table that stores the evaluation values of the second candidate ECU.
[0114] The control unit 20 of the vehicle-mounted device 2 calculates the satisfaction rate of each item in the system evaluation value (S2122). For each evaluation item in the system evaluation value table, the control unit 20 of the vehicle-mounted device 2 calculates the satisfaction rate based on the derived evaluation value, necessary condition value, and sufficient condition value: "Satisfaction rate = 1 - {(Evaluation value - Sufficient condition value) / (Necessary condition value - Sufficient condition value)}". The control unit 20 of the vehicle-mounted device 2 stores the calculated evaluation values of each evaluation item in the satisfaction rate section of the system evaluation value table in the storage unit 23.
[0115] The control unit 20 of the vehicle-mounted device 2 calculates the function configuration suitability evaluation value using the satisfaction rate and weight coefficient of each item (S2123). For each calculated evaluation value, the control unit 20 calculates the sum of the values obtained by multiplying by the corresponding weight coefficient (Σ(satisfaction rate × weight coefficient)), which is used as the function configuration suitability evaluation value. The control unit 20 of the vehicle-mounted device 2 stores the calculated function configuration suitability evaluation value (Σ(satisfaction rate × weight coefficient)) in the function configuration suitability evaluation value (summary value) item of the system evaluation value table in the storage unit 23.
[0116] The control unit 20 of the vehicle-mounted device 2 determines whether the processing of all second candidate ECUs included in the secondary list of configuration target candidates has been completed (S2124). The control unit 20 of the vehicle-mounted device 2 can determine whether the processing of all second candidate ECUs has been completed based on whether the processing of the second candidate ECUs included in the secondary list of configuration target candidates has been performed sequentially up to the second candidate ECUs listed at the end of the list. If the processing of all second candidate ECUs has not been completed (S2124: No), the control unit 20 of the vehicle-mounted device 2 performs loop processing to execute S2121 and subsequent processes again.
[0117] After processing all second candidate ECUs (S2124: Yes), the control unit 20 of the vehicle device 2 determines the second candidate ECU with the highest function configuration suitability evaluation value as the function configuration target ECU (S2125). The control unit 20 of the vehicle device 2 determines (determines) the second candidate ECU with the highest function configuration suitability evaluation value as the function configuration target ECU by comparing the function configuration suitability evaluation values stored in the system evaluation value table of each second candidate ECU stored in the storage unit 23.
[0118] Thus, when determining the target ECU for functional configuration, the control unit 20 of the vehicle-mounted device 2 performs a three-stage determination (screening) process on all vehicle-mounted ECUs 3 installed in the vehicle C. Specifically, in the first stage, when configuring software functions for all vehicle-mounted ECUs 3 installed in the vehicle C, the control unit 20 of the vehicle-mounted device 2 determines whether the ECU 3 meets the model or specification requirements (static resource conditions) such as CPU type or memory capacity. Then, in the second stage, when configuring software functions by executing additional programs, the control unit 20 of the vehicle-mounted device 2 determines whether the ECU 3 (candidate ECU) meets the requirements for dynamic resource conditions (memory utilization, maximum CPU utilization, maximum startup time) considering the running state of the existing program.
[0119] These first and second stages serve as condition determinations for the individual vehicle ECU3. However, the control unit 20 of the vehicle device 2 further performs a system evaluation, which includes evaluation items such as communication load in an environment where the vehicle ECU3 (candidate ECU) with software function configuration is connected to the vehicle network 4. In this way, by performing the third stage of condition fulfillment determination, the control unit 20 of the vehicle device 2 can not only evaluate the operation of the individual vehicle ECU3 (candidate ECU), but also perform various evaluation item determinations (system evaluation determination) in an operating environment where the candidate ECU and other vehicle ECU3 are connected to the vehicle network 4. This allows it to determine the target ECU with the most optimized function configuration for the overall vehicle C.
[0120] When performing the second stage (evaluation based on necessary resource conditions (dynamic resource conditions)) and the third stage (system evaluation based on functional configuration conditions) of the determination process, the control unit 20 of the vehicle-mounted device 2 uses necessary condition values and sufficient condition values, which are more restrictive than necessary condition values, as determination values used in determining various evaluation items. Therefore, even if there is no vehicle-mounted ECU 3 that possesses sufficient condition values in all evaluation items, it is possible to determine (identify) the vehicle-mounted ECU 3 with the highest evaluation value (functional configuration suitability evaluation value) among those that possess all necessary condition values as the functional configuration target ECU.
[0121] The control unit 20 of the vehicle-mounted device 2 receives the OTA module (S3) from the external server SV1. The control unit 20 of the vehicle-mounted device 2 receives the OTA module (additional program) for adding software functions from the external server SV1 (OTA server).
[0122] The control unit 20 of the vehicle-mounted device 2 relays the OTA module to the functional configuration target ECU (S4). The control unit 20 of the vehicle-mounted device 2 relays (sends) the OTA module (additional program) received (obtained) from the external server SV1 (OTA server) to the functional configuration target ECU (vehicle-mounted ECU3) determined (determined) by the processing of S2081 or S212. After relaying (sending) the OTA module (additional program) to the functional configuration target ECU (vehicle-mounted ECU3), the control unit 20 of the vehicle-mounted device 2 can also cause the functional configuration target ECU to execute the OTA module (additional program) by sending an activation signal to the functional configuration target ECU.
[0123] (Implementation Method 2)
[0124] Figure 14 This is a flowchart illustrating the processing of the control unit 20 of the vehicle-mounted device 2 in Embodiment 2 (simulated by an external server SV1). In this embodiment, the external server SV1 (OTA server) uses vehicle information sent from the vehicle-mounted device 2 to determine the vehicle-mounted ECU 3, i.e., the function configuration target ECU, to which the OTA module (additional program) to be sent to the vehicle-mounted device 2. The control unit 20 of the vehicle-mounted device 2 obtains information about the determined function configuration target ECU from the external server SV1 (OTA server) and obtains the OTA module (additional program).
[0125] The control unit 20 of the vehicle device 2 detects the OTA start event (S21). The control unit 20 of the vehicle device 2 performs the same processing as S1 in Embodiment 1 in S21.
[0126] The control unit 20 of the vehicle-mounted device 2 sends vehicle information to the external server SV1 (S22). The control unit 20 of the vehicle-mounted device 2 also sends vehicle information stored in the storage unit 23 to the external server SV1. The vehicle information sent by the vehicle-mounted device 2 to the external server SV1 is the same as the vehicle information in Embodiment 1.
[0127] External server SV1 uses vehicle information from vehicle-mounted device 2 to perform the same processing as S2 performed by vehicle-mounted device 2 in Embodiment 1, thereby determining the target ECU for function configuration. External server SV1 sends information about the determined target ECU for function configuration to vehicle-mounted device 2.
[0128] The control unit 20 of the vehicle-mounted device 2 obtains information about the target ECU for functional configuration determined by the external server SV1 (S23). The control unit 20 of the vehicle-mounted device 2 obtains information about the target ECU for functional configuration determined by the external server SV1 from the external server SV1.
[0129] The control unit 20 of the vehicle-mounted device 2 receives the OTA module from the external server SV1 (S24). The control unit 20 of the vehicle-mounted device 2 relays the OTA module to the function configuration target ECU (S25). The control unit 20 of the vehicle-mounted device 2 performs the same processes S24 to S25 as those in Embodiment 1 (S3 to S4).
[0130] The embodiments disclosed herein are exemplary in all respects and should not be considered limiting. The scope of this disclosure is defined by the claims, not the foregoing description, and is intended to include all modifications within the meaning and scope equivalent to the claims.
[0131] Regarding multiple claims recited in the claims statement, they can be combined with each other regardless of their form of reference. The claims statement may include multiple dependent claims that are subordinate to multiple claims. Even if no multiple dependent claims are recited, this does not limit the possibility of reciting multiple dependent claims that are subordinate to multiple dependent claims.
[0132] Explanation of reference numerals in the attached figures
[0133] Vehicle C
[0134] S vehicle system
[0135] SV1 External Server (OTA Server)
[0136] N External Network
[0137] 1. External communication device
[0138] 11 antennas
[0139] 2. Vehicle-mounted device (OTA host)
[0140] 20 Control Department
[0141] 21 Input / Output Interfaces
[0142] 22. In-vehicle communication department
[0143] 23 Storage Department
[0144] M recording medium
[0145] P Control program (program product)
[0146] 3. On-board ECUs (candidate ECU, second candidate ECU, target ECU for functional configuration)
[0147] 4. In-vehicle network
[0148] 41 Communication Line
Claims
1. An in-vehicle device comprising a control unit that acquires an additional program sent from an external server outside the vehicle and executes processing for applying the additional program to an in-vehicle ECU mounted on the vehicle, wherein, The control unit obtains information about the target ECU for functional configuration, which is one of the multiple on-board ECUs installed in the vehicle, determined based on the determination results regarding necessary resource conditions and functional configuration conditions. The control unit, based on the acquired information, relays the additional program obtained from the external server to the target ECU for the determined function configuration.
2. The vehicle-mounted device according to claim 1, wherein, The determination of the necessary resource conditions and the functional configuration conditions is performed by the external server. The control unit outputs vehicle information, including information about the resources of each of the multiple on-board ECUs, to the external server. The control unit obtains information from the external server regarding the target ECU for the function configuration, which is determined by the external server based on the vehicle information, the necessary resource conditions in the additional program, and the function configuration conditions.
3. The vehicle-mounted device according to claim 1, wherein, The control unit obtains from the external server the necessary resource conditions and functional configuration conditions required in the on-board ECU or the vehicle when executing the additional program. The control unit extracts one or more of the vehicle ECUs that meet the necessary resource conditions from among the multiple vehicle ECUs as candidate ECUs. The control unit determines the candidate ECU that meets the functional configuration conditions from the extracted candidate ECUs as the functional configuration target ECU.
4. The vehicle-mounted device according to claim 3, wherein, The necessary resource conditions include at least one of the following: storage capacity, CPU model, and operating frequency of the vehicle ECU.
5. The vehicle-mounted device according to claim 4, wherein, The function configuration conditions include necessary function configuration conditions and sufficient function configuration conditions that impose more restrictions than the necessary function configuration conditions. The control unit determines whether there is a candidate ECU among the extracted candidate ECUs that meets the conditions for sufficient functional configuration. If a candidate ECU possesses sufficient conditions for the aforementioned functional configuration exists, the control unit will determine that candidate ECU as the target ECU for the functional configuration. If there is no candidate ECU that meets the sufficient conditions for the aforementioned functional configuration, the control unit determines whether there is a candidate ECU that meets the necessary conditions for the aforementioned functional configuration.
6. The vehicle-mounted device according to claim 5, wherein, When the control unit extracts multiple candidate ECUs, it sequentially determines whether each candidate ECU possesses the sufficient conditions for functional configuration. If a candidate ECU is determined to have sufficient conditions for the aforementioned functional configuration... The control unit interrupts the determination process of the sufficient conditions for the function configuration, and does not perform the determination process for the undetermined candidate ECUs that are in the order of the candidate ECU.
7. The vehicle-mounted device according to claim 6, wherein, The functional configuration conditions include multiple configuration condition items. The control unit extracts the candidate ECUs that meet the necessary conditions for the aforementioned functional configuration as the second candidate ECU. The control unit calculates the satisfaction rate of each configuration condition item in each of the second candidate ECUs. The control unit determines the target ECU for the functional configuration based on the satisfaction rate among each of the second candidate ECUs.
8. The vehicle-mounted device according to claim 7, wherein, Each of the configuration condition items is associated with a weight coefficient corresponding to its importance. The control unit calculates the sum of the values obtained by multiplying the satisfaction rate of each configuration condition item by the weighting coefficient in each of the second candidate ECUs. The control unit determines the second candidate ECU with the largest total value as the target ECU for the function configuration.
9. The vehicle-mounted device according to claim 8, wherein, The functional configuration conditions include at least one of the following: memory usage rate, CPU usage rate, allowable latency time, maximum startup time, bus load rate in the vehicle network, and relay latency time.
10. A program for causing a computer to perform the following processing: the computer receives an additional program sent from an external server outside the vehicle and performs processing for applying the additional program to an on-board ECU mounted on the vehicle: Information is obtained regarding the target ECU for functional configuration, which is one of the multiple on-board ECUs installed in the vehicle, determined based on the results of determinations regarding necessary resource conditions and functional configuration conditions. The additional program is obtained from the external server by the target ECU relay for the function configuration.
11. An information processing method for causing a computer to perform the following processing: the computer obtains an additional program sent from an external server outside the vehicle, and performs processing for applying the additional program to an on-board ECU mounted on the vehicle: Information is obtained regarding the target ECU for functional configuration, which is one of the multiple on-board ECUs installed in the vehicle, determined based on the results of determinations regarding necessary resource conditions and functional configuration conditions. The additional program is obtained from the external server by the target ECU relay for the function configuration.