Setting management device, setting management method, and setting management program

Abstract

This setting management device comprises: an acquisition unit for acquiring configuration information indicating the configuration of one or more on-vehicle devices connected to an on-vehicle network and the configuration of the on-vehicle network when updating software of the one or more on-vehicle device connected to the on-vehicle network; an assessment unit for executing a simulation of the operation of the one or more on-vehicle devices after the software update on the basis of the configuration information acquired by the acquisition unit, and assessing whether the operation of the one or more on-vehicle devices after the software update is established; and a determination unit for determining setting information of the one or more on-vehicle devices after the software update on the basis of the amount of electric power consumed due to the operation of the one or more on-vehicle devices assessed by the assessment unit to be established.

Description

Setting management device, setting management method, and setting management program

[0001] This disclosure relates to a setting management device, a setting management method, and a setting management program. This application claims priority to Japanese Application No. 2024-034767 filed on March 7, 2024, and incorporates by reference the entire contents of that Japanese application.

[0002] A vehicle is equipped with a variety of on-board devices, such as control system ECUs (Electronic Control Units) that control the engine, transmission, etc., body system ECUs that control headlights, power windows, etc., and information system ECUs for navigation systems, multimedia devices, etc. Each on-board device is connected to an on-board network and can communicate with each other. Various software programs run in these ECUs to realize their respective functions.

[0003] Patent document 1 discloses a method for switching the operation of a relay device that relays communications between communication buses in an in-vehicle network between low-power operation and high-processing-capability operation depending on the operating state of the vehicle.

[0004] International Publication No. 2016 / 111213

[0005] A setting management device according to one aspect of the present disclosure includes an acquisition unit that, when updating software on an in-vehicle device connected to an in-vehicle network, acquires configuration information indicating the configuration of one or more in-vehicle devices connected to the in-vehicle network and the configuration of the in-vehicle network; a determination unit that performs a simulation of the operation of the one or more in-vehicle devices after the software update based on the configuration information acquired by the acquisition unit and determines whether the operation of the one or more in-vehicle devices after the software update is valid; and a determination unit that determines setting information for the one or more in-vehicle devices after the software update based on power consumption due to the operation of the one or more in-vehicle devices that is determined to be valid by the determination unit.

[0006] FIG. 1 is a block diagram showing an example of the configuration of an in-vehicle system according to an embodiment. FIG. 2 is a block diagram showing an example of the hardware configuration of a server according to an embodiment. FIG. 3 is a functional block diagram showing an example of the functions of the server according to an embodiment. FIG. 4 is a diagram showing an example of the configuration of a vehicle information database. FIG. 5A is a diagram showing an example of a part of the configuration of an ECU database, and is a diagram showing a first table. FIG. 5B is a diagram showing an example of another part of the configuration of the ECU database, and is a diagram showing a second table. FIG. 6 is a sequence diagram showing an example of setting management of an in-vehicle network in a setting management system according to an embodiment. FIG. 7 is a flowchart showing an example of setting management processing.

[0007] <Problem to be Solved by the Present Disclosure> However, in the method disclosed in Patent Document 1, only the relay device is subject to switching of operation, and power consumption in the entire in-vehicle network cannot be optimized.

[0008] <Effects of the Present Disclosure> According to the present disclosure, it is possible to set the power consumption of the entire in-vehicle network according to the state of the in-vehicle network.

[0009] <Outline of Embodiments of the Present Disclosure> Below, an outline of embodiments of the present disclosure will be listed and described.

[0010] (1) A setting management device according to this embodiment includes: an acquisition unit that acquires, when updating software of an in-vehicle device connected to an in-vehicle network, configuration information indicating the configuration of one or more in-vehicle devices connected to the in-vehicle network and the configuration of the in-vehicle network; a determination unit that executes a simulation of operation of the one or more in-vehicle devices after the software update based on the configuration information acquired by the acquisition unit and determines whether the operation of the one or more in-vehicle devices after the software update is valid; and a determination unit that determines configuration information for the one or more in-vehicle devices after the software update based on power consumption caused by the operation of the one or more in-vehicle devices that is determined to be valid by the determination unit. This makes it possible to set power consumption of the entire in-vehicle network according to the state of the in-vehicle network when the software is updated, using the determined configuration information for the one or more in-vehicle devices.

[0011] (2) In the above (1), the determination unit may determine whether the operation of the one or more in-vehicle devices after the software update satisfies a condition for establishment, thereby determining whether the operation of the one or more in-vehicle devices is established. This makes it possible to determine the establishment of the operation of the one or more in-vehicle devices based on whether the operation state of the simulation result satisfies the condition for establishment.

[0012] (3) In the above (2), the condition for fulfillment may include a transmission time of the data from a data sender to a destination, thereby determining whether the operation of one or more in-vehicle devices is feasible based on whether the end-to-end transmission time of the data is equal to or shorter than a required transmission time included in the condition for fulfillment.

[0013] (4) In the above (2) or (3), the condition for fulfilling may include a data transmission cycle, whereby the feasibility of operation of one or more in-vehicle devices can be determined based on whether the data transmission cycle in the in-vehicle network is equal to or shorter than a required cycle included in the condition for fulfilling.

[0014] (5) In any one of (1) to (4) above, the determination unit may execute a simulation of the operation of the one or more in-vehicle devices under a first operating condition and a second operating condition for the one or more in-vehicle devices, and determine whether the operation of the one or more in-vehicle devices after the software update is established under the first operating condition and the second operating condition. This makes it possible to determine whether the operation of the one or more in-vehicle devices is established for each of a plurality of operating conditions.

[0015] (6) In the above (5), the determination unit may determine the operating condition of the one or more in-vehicle devices after the software update to be one of the first operating condition and the second operating condition that has the lowest power consumption, and determine the setting information based on the determined one of the first operating condition and the second operating condition. This allows the one or more in-vehicle devices to be configured under the operating condition with the lowest power consumption.

[0016] (7) In the above (5), when the determination unit determines that the operation of the one or more in-vehicle devices under the first operating condition is established and the operation of the one or more in-vehicle devices under the second operating condition is not established, the determination unit may determine the operating condition of the one or more in-vehicle devices after the software update to be the first operating condition, and determine the setting information based on the determined first operating condition. This makes it possible to set the one or more in-vehicle devices according to the established operating condition.

[0017] (8) In any one of (5) to (7) above, the first operating condition may include a first clock frequency of a processor mounted on the one or more on-vehicle devices, the second operating condition may include a second clock frequency of the processor, and when the first operating condition is determined by the determination unit, the setting information may include the first clock frequency, and when the second operating condition is determined by the determination unit, the setting information may include the second clock frequency. This makes it possible to appropriately set the clock frequency of the processor of the one or more on-vehicle devices.

[0018] (9) In any one of (5) to (8) above, the first operating condition may include a first number of used cores in a processor mounted on the one or more on-vehicle devices, the second operating condition may include a second number of used cores in the processor, and when the first operating condition is determined by the determination unit, the setting information may include the first number of used cores, and when the second operating condition is determined by the determination unit, the setting information may include the second number of used cores. This makes it possible to appropriately set the number of used cores in the processor of the one or more on-vehicle devices.

[0019] (10) In any one of (5) to (9) above, the first operating condition may include a first transmission cycle of data in the one or more in-vehicle devices, the second operating condition may include a second transmission cycle of data in the one or more in-vehicle devices, and when the first operating condition is determined by the determination unit, the setting information may include the first transmission cycle, and when the second operating condition is determined by the determination unit, the setting information may include the second transmission cycle. This makes it possible to appropriately set the data transmission cycle in the one or more in-vehicle devices.

[0020] (11) In any one of (1) to (10) above, the setting management device may be an external device disposed outside the vehicle, and the in-vehicle network may be communicably connected to the setting management device. This eliminates the need to install a high-performance setting management device that executes simulations in the vehicle, thereby reducing costs.

[0021] (12) In any one of (1) to (10) above, the setting management device may be an in-vehicle device connected to the in-vehicle network. This eliminates the need to communicate with an external device for the setting information, and allows the setting information to be provided to the in-vehicle device without being affected by communication conditions with the outside of the vehicle.

[0022] (13) A setting management method according to this embodiment includes, when updating software of an in-vehicle device connected to an in-vehicle network, a step of acquiring configuration information indicating the configuration of one or more in-vehicle devices connected to the in-vehicle network and the configuration of the in-vehicle network, a step of simulating operation of the one or more in-vehicle devices after the software update based on the acquired configuration information and determining whether the operation of the one or more in-vehicle devices after the software update will be established, and a step of determining setting information for the one or more in-vehicle devices after the software update based on power consumption caused by the operation of the one or more in-vehicle devices that has been determined to be established. This makes it possible to set the power consumption of the entire in-vehicle network according to the state of the in-vehicle network when the software is updated, using the determined setting information for the one or more in-vehicle devices.

[0023] (14) A setting management program according to the present embodiment causes a computer to execute, when updating software of an in-vehicle device connected to an in-vehicle network, the steps of acquiring configuration information indicating the configuration of one or more in-vehicle devices connected to the in-vehicle network and the configuration of the in-vehicle network, simulating operation of the one or more in-vehicle devices after the software update based on the acquired configuration information and determining whether the operation of the one or more in-vehicle devices after the software update will be established, and determining setting information for the one or more in-vehicle devices after the software update based on power consumption caused by the operation of the one or more in-vehicle devices that is determined to be established. This makes it possible to set the power consumption of the entire in-vehicle network according to the state of the in-vehicle network when the software is updated, using the determined setting information for the one or more in-vehicle devices.

[0024] The present disclosure can be realized not only as a setting management device having the above-described characteristic configuration, a setting management method having characteristic processing steps, and a setting management program for causing a computer to execute the characteristic processing, but also as a setting management system including the setting management device, or as a semiconductor integrated circuit in which part or all of the setting management device is implemented.

[0025] <Details of the embodiments of the present disclosure> Hereinafter, the details of the embodiments of the present disclosure will be described with reference to the drawings. Note that at least some of the embodiments described below may be combined in any manner.

[0026] 1. In-Vehicle System Fig. 1 is a block diagram showing an example of the configuration of an in-vehicle system according to an embodiment. A vehicle is equipped with an in-vehicle network 100. The in-vehicle network 100 according to the first embodiment is a CAN (Controller Area Network) network capable of communication via CAN. The in-vehicle network 100 includes buses 400A, 400B, and 400C, which are CAN buses.

[0027] The in-vehicle system 10 includes a relay ECU 200 and ECUs 300A, 300B, 300C, 300D, and 300E.

[0028] Multiple ECUs 300A, 300B, 300C, 300D, and 300E are disposed in various parts of the vehicle. The ECUs 300A, 300B, 300C, 300D, and 300E individually control the hardware of each part of the vehicle, and detect or monitor the state of the hardware of each part of the vehicle, the state around the vehicle, or objects around the vehicle. For example, the ECUs 300A, 300B, 300C, 300D, and 300E are ECUs for a control system, a body system, and an information system. In the following description, the ECUs 300A, 300B, 300C, and 300D are also collectively referred to as "ECU 300."

[0029] The functions of ECU 300 are realized by software. That is, ECU 300 can store and execute application software for individually controlling the hardware of each part of the vehicle, detecting or monitoring the state of the hardware of each part of the vehicle, the state around the vehicle, or objects around the vehicle.

[0030] The relay ECU 200 is connected to ECUs 300A, 300B, 300C, 300D, and 300E, respectively, via buses 400A, 400B, and 400C. Specifically, ECUs 300A and 300B are connected to bus 400A. ECUs 300C and 300D are connected to bus 400B. ECU 300E is connected to bus 400C. The relay ECU 200 can communicate with each of ECUs 300A, 300B, 300C, 300D, and 300E. The relay ECU 200 and ECUs 300A, 300B, 300C, 300D, and 300E are examples of "on-vehicle devices."

[0031] In one example, the in-vehicle network 100 is divided by function. For example, the bus 400A is a control system bus, and the control system ECUs 300A and 300B are connected to the bus 400A. For example, the bus 400A is a body system bus, and the body system ECUs 300C and 300D are connected to the bus 400B. For example, the bus 400A is an information system bus, and the information system ECU 300E is connected to the bus 400C.

[0032] The relay ECU 200 and the ECU 300 use a communication protocol for periodically or aperiodically transmitting and receiving messages. The communication protocol is, for example, CAN or CAN FD (CAN with Flexible Data Rate). In another example, the communication protocol is Ethernet (registered trademark). When the Ethernet protocol is used, the in-vehicle network becomes an Ethernet network having a star-shaped network topology.

[0033] The relay ECU 200 functions as a gateway that relays communications between a plurality of ECUs 300. Specifically, the relay ECU 200 relays communications (frames) between the buses 400A, 400B, and 400C. The ECUs 300 can transmit frames. The frames are messages that comply with the above-described communication protocol. The relay ECU 200 relays frames between the buses 400A, 400B, and 400C.

[0034] The functions of the relay ECU 200 are realized by software, that is, the relay ECU 200 stores application software for relaying frames and can execute the application software.

[0035] The relay ECU 200 is connected to an external communication device 350 via a bus 400C. The external communication device 350 is, for example, a TCU (Telematics Control Unit) and can communicate with devices outside the vehicle. The external communication device 350 has a wireless communication interface for a mobile communication system, such as a fifth-generation mobile communication system (5G) or a fourth-generation mobile communication system (4G). The external communication device 350 can transmit and receive packets of, for example, TCP / IP (Transmission Control Protocol / Internet Protocol). The external communication device 350 is logically connected to a base station (not shown) of a mobile communication network and can communicate with devices connected to the Internet via the base station. Specifically, the external communication device 350 can communicate with a server 500. The external communication device 350 relays communication between the relay ECU 200 and the server 500.

[0036] The server 500 manages application software updates for the relay ECU 200 and the ECU 300. The server 500 provides software for updating application programs (hereinafter also referred to as "update software" or "update SW") to the relay ECU 200 and the ECU 300. That is, the server 500 transmits the update software when an application software update is required. Communication of the application software includes changing functions implemented by the application software (changing at least a portion of the functions), adding functions, and deleting functions. The server 500 is a so-called OTA (Over The Air) server. The external communication device 350 receives the update software and transfers the received update software to the in-vehicle device to be updated, i.e., the relay ECU 200 or the ECU 300. Upon receiving the update software, the in-vehicle device to be updated restarts and executes the update software after the restart, thereby updating the application software. The setting management system 20 includes the in-vehicle system 10 and the server 500.

[0037] The server 500 is connected to an ECU database 600 and a vehicle information database 700 (hereinafter, the databases are also referred to as "DBs"). The ECU DB 600 stores configuration information of the ECUs (hereinafter, also referred to as "ECU configuration information"). The vehicle information DB 700 stores configuration information of the in-vehicle network (hereinafter, also referred to as "network configuration information"). Details of the ECU DB 600 and the vehicle information DB 700 will be described later.

[0038] 2 is a block diagram showing an example of the hardware configuration of a server according to an embodiment. The server 500 includes a processor 501, a non-volatile memory 502, a volatile memory 503, and a communication interface (hereinafter also referred to as "communication I / F") 504.

[0039] The processor 501, the nonvolatile memory 502, the volatile memory 503, and the communication I / F 504 are connected to one another by a bus (data bus) 505. The processor 501, the nonvolatile memory 502, the volatile memory 503, and the communication I / F 504 can transmit data to one another via the bus 505.

[0040] The volatile memory 503 is a semiconductor memory such as a static random access memory (SRAM) or a dynamic random access memory (DRAM). The nonvolatile memory 502 is a rewritable nonvolatile memory such as a flash memory or a hard disk. A setting management program 510 is stored in the nonvolatile memory 502. The functions of the server 500 are realized by the processor 501 executing the setting management program 510. The server 500 is an example of a "setting management device."

[0041] The processor 501 is, for example, a CPU (Central Processing Unit). However, the processor 501 is not limited to a CPU. The processor 501 may be a GPU (Graphics Processing Unit). In a specific example, the processor 501 is a multi-core processor. The processor 501 may be a single-core processor. The processor 501 is configured to be able to execute a computer program. However, the processor 501 may be, for example, an ASIC (Application Specific Integrated Circuit) or a programmable logic device such as an FPGA (Field Programmable Gate Array). In this case, the programmable logic device is configured to be able to execute the same function as the setting management program 510.

[0042] The setting management program 510 is a computer program that causes the server 500 to execute setting management processing. The setting management program 510 includes a simulation model 520. The simulation model 520 is a model for executing a simulation of the operation of the in-vehicle network. The simulation model 520 is an incomplete model, and by setting configuration information and operating conditions of the in-vehicle network 100 in the simulation model 520, a model that simulates the in-vehicle network 100 can be constructed. Details of the simulation model 520 will be described later.

[0043] The communication I / F 504 includes, for example, a wireless communication interface compliant with 5G. The communication I / F 504 includes a wireless antenna and is capable of wireless communication with the external communication device 350. The communication I / F 504 also includes, for example, a wired communication interface such as an Ethernet interface. The communication I / F 504 is capable of communicating with the ECU DB 600 and the vehicle information DB 700.

[0044] 3. Functions of the Server FIG. 3 is a functional block diagram showing an example of functions of the server according to the embodiment.

[0045] The server 500 has the functions of an acquisition unit 511, a construction unit 512, a determination unit 513, a calculation unit 514, a decision unit 515, and an output unit 516. The acquisition unit 511, the construction unit 512, the determination unit 513, the calculation unit 514, the decision unit 515, and the output unit 516 are each realized by the processor 501 executing the setting management program 510.

[0046] When at least one of the ECUs 300A, 300B, 300C, 300D, and 300E, the relay ECU 200, and the external communication device 350 connected to the in-vehicle network 100 updates application software, the acquisition unit 511 acquires configuration information indicating the configurations of the ECUs 300A, 300B, 300C, 300D, and 300E, the relay ECU 200, and the external communication device 350, and the configuration of the in-vehicle network 100. For example, the configuration information includes ECU configuration information indicating the configurations of the ECUs 300A, 300B, 300C, 300D, and 300E, the relay ECU 200, and the external communication device 350, and network configuration information (hereinafter also referred to as "NW configuration information") indicating the configuration of the in-vehicle network 100.

[0047] For example, the ECU configuration information is stored in the ECU DB 600. The NW configuration information is stored in the vehicle information DB 700. In one example, the acquisition unit 511 acquires the ECU configuration information from the ECU DB 600 and acquires the NW configuration information from the vehicle information DB 700. However, the ECU configuration information and the NW configuration information may be stored in a single database. In this case, the acquisition unit 511 acquires the ECU configuration information and the NW configuration information from a single database.

[0048] Fig. 4 is a diagram showing an example of the configuration of the vehicle information DB. The configuration of an in-vehicle network is determined for each vehicle model, for example. The vehicle information DB 700 stores configuration information of the in-vehicle network for each vehicle model, for example. In the example of Fig. 4, the network configuration information of vehicle model A is stored corresponding to vehicle model A, and the network configuration information of vehicle model B is stored corresponding to vehicle model B. Note that the vehicle information DB 700 may store network configuration information for each vehicle.

[0049] The NW configuration information includes information about the communication lines that make up the in-vehicle network 100. That is, the in-vehicle network 100 is divided into partial networks for each communication line, and the NW configuration information includes configuration information about each partial network.

[0050] For example, the information on the partial network includes identification information (ECU list) of ECUs belonging to the partial network, a communication protocol used in the partial network, and a setting of the communication protocol. In the example of Fig. 4, the identification information of ECUs 300A, 300B, and relay ECU 200 connected to bus 400A corresponds to bus 400A as a communication line. The identification information of ECUs 300C, 300D, and relay ECU 200 connected to bus 400B corresponds to bus 400B as a communication line. The identification information of ECU 300E, relay ECU 200, and external communication device 350 connected to bus 400C corresponds to bus 400C as a communication line.

[0051] 4, CAN, which is a communication protocol used in bus 400A, corresponds to bus 400A as a communication line. CAN FD, which is a communication protocol used in bus 400B, corresponds to bus 400B as a communication line. CAN FD, which is a communication protocol used in bus 400C, corresponds to bus 400C as a communication line.

[0052] In the example of Fig. 4, bus 400A as a communication line corresponds to a transmission speed of 500 kbps, which is the CAN setting of bus 400A. Bus 400B as a communication line corresponds to a transmission speed of 5 Mbps, which is the CAN FD setting of bus 400B. Bus 400C as a communication line corresponds to a transmission speed of 5 Mbps, which is the CAN FD setting of bus 400C.

[0053] 5A and 5B are diagrams showing an example of the configuration of the ECUDB. The configuration of an ECU is determined for each ECU model. The ECUDB 600 stores, for example, ECU configuration information for each ECU model. The ECUDB 600 includes a first table 600A and a second table 600B.

[0054] Each ECU (including ECU 300, relay ECU 200, and external communication device 350) includes a processor. The processor of an ECU can operate at one or more clock frequencies. For example, the operable clock frequencies (hereinafter also referred to as "operable frequencies") of the processor of an ECU of type "A100" are 120 MHz and 240 MHz. The operable frequencies of the processor of an ECU of type "B200" are 60 MHz and 120 MHz. The operable frequencies of the processor of an ECU of type "C300" are 120 MHz and 240 MHz. The first table 600A stores the operable frequencies of the processors as described above in correspondence with the ECU types.

[0055] The processor of each ECU includes one or more cores. For example, the number of cores of the processor of an ECU of model "A100" is "2," and it operates in either a mode using one core (number of used cores: "1") or a mode using two cores (number of used cores: "2"). The number of cores of the processor of an ECU of model "B200" is "1," and it operates only with the number of used cores: "1." The number of cores of the processor of an ECU of model "C300" is "2," and it operates with either the number of used cores: "1" or the number of used cores: "2." The first table 600A stores the number of used cores of the processor as described above, corresponding to the model of the ECU.

[0056] Each ECU transmits and receives data of a type corresponding to its function. For example, an ECU of type "A100" is an ECU for brake control and is assigned the function "brake control." The brake control ECU transmits and receives data related to brakes (i.e., data of type "brake"). For example, a data ID is assigned to each data type, and a frame transmitted through the in-vehicle network 100 is assigned a data ID corresponding to the data stored in the frame. Various types of data are transmitted periodically through the in-vehicle network 100. The data transmission cycle is determined for each data type. For example, the data ID for the type "brake" is "100," and the communication cycle (transmission cycle) is "10 ms." The second table 600B stores the above-mentioned functions, data IDs, and communication cycles corresponding to the ECU model.

[0057] Returning to FIG. 3 , when an ECU updates application software, part of the ECU configuration information (vehicle configuration information) is transmitted from the vehicle to the server 500. The acquisition unit 511 may receive the vehicle configuration information transmitted from the vehicle in this manner and acquire it as part of the ECU configuration information and the NW configuration information. As another example, the acquisition unit 511 may request the configuration information from the vehicle. For example, the relay ECU 200 receives a request from the server 500 and collects the ECU configuration information and the NW configuration information. For example, the ECU configuration information is collected from each ECU. For example, the NW configuration information may be stored in the relay ECU 200, and the relay ECU 200 may read the stored NW configuration information. The relay ECU 200 transmits the collected ECU configuration information and NW configuration information to the server 500, and the acquisition unit 511 receives the ECU configuration information and the NW configuration information.

[0058] The construction unit 512 constructs a simulation model 520 of the in-vehicle system 10 after the application software update, based on the configuration information acquired by the acquisition unit 511. That is, the construction unit 512 sets ECU configuration information and NW configuration information in the incomplete simulation model 520, and constructs the simulation model 520 that virtually approximates the in-vehicle system 10 after the application software update.

[0059] The construction unit 512 further sets operating conditions for the simulation model 520. The operating conditions include, for example, the clock frequency of the processor of each ECU, the number of used cores, and the data communication cycle. That is, for an ECU that can set two operable frequencies, for example, 120 MHz and 240 MHz, one of the clock frequencies 120 MHz and 240 MHz is specified as the operating condition. For example, for an ECU that can set two numbers of used cores, for example, one core or two cores, one of the numbers of used cores, one core or two cores, is specified as the operating condition. For example, one communication cycle from the settable range of communication cycles for data of the data type "brake" (e.g., 10 ms to 65,000 ms) is specified as the operating condition. That is, the operating conditions of an ECU include multiple items (e.g., clock frequency, number of used cores, data communication cycle), and the construction unit 512 can specify multiple combinations of values ​​for the multiple items. In a specific example, the constructor 512 sequentially sets each of a plurality of operating conditions for all combinations of values ​​of a plurality of items in the simulation model 520 .

[0060] The determination unit 513 uses the simulation model 520 constructed by the construction unit 512 to simulate the operation of the in-vehicle system 10. In a specific example, the determination unit 513 simulates the operation of the in-vehicle system 10 under one of a plurality of operating conditions using the simulation model 520 in which the operating condition is set. When the simulation of the operation of the in-vehicle system 10 under one operating condition is completed, the determination unit 513 simulates the operation of the in-vehicle system 10 under the next operating condition. In this way, a plurality of operating conditions are sequentially set in the simulation model 520, and the determination unit 513 sequentially performs simulations under a plurality of operating conditions using each of the simulation models 520 in which each operating condition is set.

[0061] In the simulation, data is repeatedly input to and output from the virtual in-vehicle system 10 (simulation model 520) over time. The determination unit 513 acquires state information of the virtual in-vehicle system 10 (simulation model 520) that changes depending on the operating conditions. The determination unit 513 may store the acquired state information in the non-volatile memory 502 as an operation log for the simulation in association with the operating conditions. The state information includes, for example, the transmission time of the data from the source to the destination, the retention time of the data in the relay ECU 200, and the communication cycle of the data.

[0062] The determination unit 513 determines whether the operation of the in-vehicle system 10 after the application software update is valid based on the execution result of the simulation. For example, the determination unit 513 determines whether the operation of the in-vehicle system 10 after the application software update satisfies a validity condition, thereby determining whether the operation of the in-vehicle system 10 is valid.

[0063] In a specific example, the determining unit 513 compares the acquired state information with the condition to be met, and determines whether the state information satisfies the condition.

[0064] The fulfillment conditions are conditions required for the in-vehicle system 10. For example, the fulfillment conditions are stored in the non-volatile memory 502 in advance.

[0065] For example, the fulfillment conditions include a condition for the transmission time from the source of data to the destination. The required transmission time (delay time) for each type of data is determined. For example, data transmitted and received by a control system ECU (control system data) cannot tolerate a delay of more than a certain amount (e.g., a delay exceeding 100 μs). On the other hand, data transmitted and received by an information system ECU (information system data) can tolerate a longer delay time (e.g., a delay of up to 1 ms). The fulfillment conditions include a condition for the transmission time from the source of data to the destination (hereinafter also referred to as "end-to-end delay time") for each type of data.

[0066] For example, the fulfillment condition includes a condition for the data communication cycle. For example, data used for engine control is repeatedly transmitted at short cycles. On the other hand, data used for door control is transmitted at longer cycles than data for engine control. In other words, the communication cycle for control system data is short, and the communication cycle for body system data is long. The fulfillment condition defines a communication cycle condition for each type of data.

[0067] The determination unit 513 compares the value included in the status information with the condition included in the condition for each item, for example, and determines that the status information satisfies the condition if the values ​​included in the status information for all items satisfy the condition. The determination unit 513 determines that the status information does not satisfy the condition if the value included in the status information for at least one item does not satisfy the condition. For example, if the end-to-end delay time of the data of the type "brake" included in the status information is "15 μs" and the condition for the end-to-end delay time of the data of the type "brake" included in the condition for the condition is "30 μs or less," the end-to-end delay time of the data of the type "brake" satisfies the condition. If the communication cycle of the data of the type "brake" included in the status information is "100 ms" and the condition for the communication cycle of the data of the type "brake" included in the condition for the condition is "10 ms or more and 50 ms or less," the communication cycle of the data of the type "brake" does not satisfy the condition.

[0068] The calculation unit 514 calculates the power consumption due to the operation of the in-vehicle system 10 under the operating conditions determined to be met by the determination unit 513. For example, a simulation model 520 is used to calculate the power consumption. That is, a simulation of the operation of the in-vehicle system 10 is executed using the simulation model 520, and the processing loads of the ECU 300, the relay ECU 200, and the external communication device 350 at each time are calculated. The calculation unit 514 estimates the power consumption of each of the ECU 300, the relay ECU 200, and the external communication device 350 from the processing loads of the ECU 300, the relay ECU 200, and the external communication device 350 at each time, and can calculate the power consumption of the in-vehicle system 10 by summing up the estimated power consumptions.

[0069] The determination unit 515 determines the setting information for the in-vehicle system 10 after the software update based on the power consumption of the in-vehicle system 10 calculated by the calculation unit 514. For example, the determination unit 515 determines (selects) one operating condition with the lowest calculated power consumption from among multiple operating conditions that satisfy the conditions. For example, if there is one operating condition that satisfies the conditions, the determination unit 515 selects that operating condition. The determination unit 515 determines the setting information based on the selected operating condition.

[0070] For example, the setting information includes the selected operating conditions. That is, the setting information includes the clock frequencies, the number of used cores, and the data communication cycle of the ECU 300, the relay ECU 200, and the external communication device 350 under the operating conditions with the lowest power consumption obtained by the simulation. The setting information may include information other than the selected operating conditions.

[0071] The output unit 516 outputs the setting information determined by the determination unit 515. In a specific example, the output unit 516 transmits the setting information determined by the determination unit 515 to the vehicle. For example, the output unit 516 may transmit the setting information to the vehicle together with the updated software.

[0072] 4. Operation of the Setting Management System FIG. 6 is a sequence diagram showing an example of setting management of an in-vehicle network in the setting management system according to the embodiment.

[0073] When update software for one application software is stored in the OTA server 500, the application software in the ECU can be updated. The server 500 transmits update availability information notifying that an application software update is available to the relay ECU 200 that manages OTA in the vehicle (step S1). Upon receiving the update availability information, the relay ECU 200 transmits an update inquiry to each subordinate ECU 300 to inquire whether an update is necessary, i.e., whether the application software to be updated is installed (steps S2_1 and S2_2).

[0074] For example, assume that ECU 300A is a navigation ECU and that navigation application software can be updated. In this case, ECU 300A, in which application software to be updated is installed, transmits a request for software update to relay ECU 200 (step S3_1). On the other hand, ECU 300B and other ECUs, in which application software to be updated is not installed, transmit a notification that update is not required to relay ECU 200 (step S3_2).

[0075] The relay ECU 200, which has received the request for the updated software from the ECU 300A, requests the updated software from the server 500 (step S4).

[0076] The server 500 requests vehicle configuration information from the vehicle (relay ECU 200) (step S5). Upon receiving the request, the relay ECU 200 requests ECU information (e.g., part of the ECU configuration information) indicating the configuration of each ECU 300 and external communication device 350 from each ECU 300 and external communication device 350 (steps S6_1 and S6_2). Each ECU 300 and external communication device 350 transmits its own ECU information to the relay ECU 200 (steps S7_1 and S7_2).

[0077] The relay ECU 200 acquires ECU information indicating the configuration of the relay ECU 200. Furthermore, the relay ECU 200 may acquire at least a part of the configuration information of the in-vehicle network 100. The relay ECU 200 creates vehicle configuration information based on the collected information and transmits the created vehicle configuration information to the server 500 (step S8).

[0078] The server 500 executes the setting management process (step S9).

[0079] FIG. 7 is a flowchart illustrating an example of the setting management process.

[0080] The processor 501 of the server 500 acquires NW configuration information and ECU configuration information indicating the configuration of the in-vehicle network 100 after the application software update (step S101). In step S101, for example, the processor 501 can acquire the ECU configuration information from the ECU DB 600 and the NW configuration information from the vehicle information DB 700. In step S101, for example, the processor 501 can acquire the NW configuration information and the ECU configuration information using vehicle configuration information provided from the vehicle.

[0081] The processor 501 selects one of a plurality of operating conditions of the in-vehicle system 10 (step S102).

[0082] The processor 501 sets the acquired NW configuration information, ECU configuration information, and selected operating conditions in the simulation model 520, and constructs the simulation model 520 of the in-vehicle system 10 (step S103).

[0083] The processor 501 executes a simulation of the operation of the in-vehicle system 10 using the constructed simulation model 520 (step S104). The simulation generates status information of the virtual in-vehicle system 10 after the application software update.

[0084] The processor 501 determines whether the generated state information satisfies the conditions (step S105).

[0085] If the generated status information satisfies the condition (YES in step S105), processor 501 calculates the power consumption in virtual in-vehicle system 10 after the application software update using constructed simulation model 520 (step S106). On the other hand, if the generated status information does not satisfy the condition (NO in step S105), processor 501 skips step S106.

[0086] The processor 501 determines whether all the operating conditions have been selected (step S107). If an operating condition that has not been selected remains (NO in step S107), the processor 501 returns to step S102 and selects a new operating condition.

[0087] If all the operating conditions have been selected (YES in step S107), the processor 501 selects the operating condition with the lowest power consumption from among the operating conditions for which the state information satisfies the condition (step S108).

[0088] The processor 501 determines the setting information based on the selected operating conditions (step S109).

[0089] The processor 501 outputs the determined setting information (step S110). Specifically, the processor 501 stores the setting information in the non-volatile memory 502.

[0090] This completes the setting management process.

[0091] 6, when the setting management process is completed, the server 500 transmits the setting information and the update software to the vehicle (relay ECU 200) (step S10). The setting information includes information for configuring each of the ECU 300, the relay ECU 200, and the external communication device 350 (hereinafter also referred to as “individual setting information”).

[0092] When the relay ECU 200 receives the setting information and the update software, it divides the received setting information into individual setting information. The relay ECU 200 transmits the individual setting information and the update software for the ECU 300A to the ECU 300A (step S11_1). The relay ECU 200 transmits the individual setting information for the ECU 300B to the ECU 300B (step S11_2). Furthermore, the relay ECU 200 transmits the individual setting information to each of the other ECUs 300 and the external communication device 350.

[0093] The ECU 300A executes the update software to update the application software (step S12). The relay ECU 200, the ECU 300, and the external communication device 350 change their respective settings based on the individual setting information (step S13). Note that if the settings of one or more ECUs do not change before and after the application software update, the settings of the one or more ECUs do not change.

[0094] [5. Modifications] In the above-described embodiment, the server 500 is the setting management device, but this is not limiting. The relay ECU 200 may be the setting management device. In this case, the relay ECU 200 has the functions of an acquisition unit 511, a construction unit 512, a determination unit 513, a calculation unit 514, a determination unit 515, and an output unit 516.

[0095] If the relay ECU 200 is a setting management device, when it receives updateable information from the server 500, it may acquire ECU configuration information and NW configuration information, perform a simulation of the operation of the in-vehicle system 10 after the application software update, and determine the setting information.

[0096] When the relay ECU 200 is a setting management device, the relay ECU 200 may acquire the ECU configuration information and the NW configuration information from the ECU DB 600 and the vehicle information DB 700. In another example, the relay ECU 200 may acquire the ECU configuration information and the NW configuration information from the ECU 300, the external communication device 350, and the relay ECU 200.

[0097] [5. Supplementary Note] The embodiments disclosed herein are illustrative in all respects and are not restrictive. The scope of the present invention is defined by the claims, not the above-described embodiments, and includes meanings equivalent to the claims and all modifications within the scope thereof.

[0098] 10 In-vehicle system 20 Setting management system 100 In-vehicle network 200 Relay ECU (in-vehicle device) 300, 300A, 300B, 300C, 300D, 300E ECU (in-vehicle device) 350 External communication device 400A, 400B, 400C Bus 500 Server (setting management device) 501 Processor 502 Non-volatile memory 503 Volatile memory 504 Communication interface (communication I / F) 505 Bus 510 Setting management program 511 Acquisition unit 512 Construction unit 513 Determination unit 514 Calculation unit 515 Decision unit 516 Output unit 520 Simulation model 600 ECU database (ECUDB) 600A First table 600B Second table 700 Vehicle information database (vehicle information DB)

Claims

1. A setting management device comprising: an acquisition unit that, when updating software of an in-vehicle device connected to an in-vehicle network, acquires configuration information indicating the configuration of one or more in-vehicle devices connected to the in-vehicle network and the configuration of the in-vehicle network; a determination unit that, based on the configuration information acquired by the acquisition unit, executes a simulation of the operation of the one or more in-vehicle devices after the software update and determines whether the operation of the one or more in-vehicle devices after the software update will be successful; and a determination unit that determines setting information of the one or more in-vehicle devices after the software update based on the power consumption caused by the operation of the one or more in-vehicle devices that is determined to be successful by the determination unit.

2. The setting management device according to claim 1, wherein the determination unit determines whether the operation of the one or more in-vehicle devices after the software update satisfies a condition for establishment, thereby determining whether the operation is established.

3. The setting management device according to claim 2, wherein the conditions to be satisfied include a transmission time of the data from a data source to a destination.

4. The setting management device according to claim 2 or 3, wherein the conditions to be satisfied include a data transmission cycle.

5. A setting management device as described in any one of claims 1 to 4, wherein the judgment unit executes a simulation of the operation of the one or more in-vehicle devices under each of first operating conditions and second operating conditions of the one or more in-vehicle devices, and judges whether the operation of the one or more in-vehicle devices after the software update is established under each of the first operating conditions and the second conditions.

6. The setting management device described in claim 5, wherein the determination unit determines the operating conditions of the one or more in-vehicle devices after the software update to be one of the first operating conditions and the second operating conditions that has the lowest power consumption, and determines the setting information based on the determined one of the first operating conditions and the second operating conditions.

7. A setting management device as described in claim 5, wherein, when the judgment unit determines that the operation of the one or more in-vehicle devices under the first operating condition is established and the operation of the one or more in-vehicle devices under the second operating condition is not established, the determination unit determines the operating condition of the one or more in-vehicle devices after the software update to be the first operating condition, and determines the setting information based on the determined first operating condition.

8. A setting management device as described in any one of claims 5 to 7, wherein the first operating condition includes a first clock frequency in a processor installed in the one or more on-board devices, the second operating condition includes a second clock frequency in the processor, when the first operating condition is determined by the determination unit, the setting information includes the first clock frequency, and when the second operating condition is determined by the determination unit, the setting information includes the second clock frequency.

9. A setting management device as described in any one of claims 5 to 8, wherein the first operating condition includes a first number of used cores in a processor installed in the one or more on-board devices, and the second operating condition includes a second number of used cores in the processor, and when the first operating condition is determined by the determination unit, the setting information includes the first number of used cores, and when the second operating condition is determined by the determination unit, the setting information includes the second number of used cores.

10. A setting management device as described in any one of claims 5 to 9, wherein the first operating condition includes a first transmission period of data in the one or more in-vehicle devices, the second operating condition includes a second transmission period of data in the one or more in-vehicle devices, when the first operating condition is determined by the determination unit, the setting information includes the first transmission period, and when the second operating condition is determined by the determination unit, the setting information includes the second transmission period.

11. A setting management device as described in any one of claims 1 to 10, wherein the setting management device is an external device arranged outside the vehicle, and the in-vehicle network is communicatively connected to the setting management device.

12. The setting management device according to any one of claims 1 to 10, wherein the setting management device is an in-vehicle device connected to the in-vehicle network.

13. A setting management method comprising the steps of: when updating software of an in-vehicle device connected to an in-vehicle network, acquiring configuration information indicating the configuration of one or more in-vehicle devices connected to the in-vehicle network and the configuration of the in-vehicle network; simulating the operation of the one or more in-vehicle devices after the software update based on the acquired configuration information and determining whether the operation of the one or more in-vehicle devices after the software update will be successful; and determining setting information for the one or more in-vehicle devices after the software update based on power consumption caused by the operation of the one or more in-vehicle devices that is determined to be successful.

14. A setting management program for causing a computer to execute the following steps: when updating software of an in-vehicle device connected to an in-vehicle network, acquiring configuration information indicating the configuration of one or more in-vehicle devices connected to the in-vehicle network and the configuration of the in-vehicle network; simulating the operation of the one or more in-vehicle devices after the software update based on the acquired configuration information and determining whether the operation of the one or more in-vehicle devices after the software update will be successful; and determining setting information for the one or more in-vehicle devices after the software update based on the power consumption caused by the operation of the one or more in-vehicle devices that is determined to be successful.

Images