Setting management apparatus, setting management method, and setting management program

Abstract

To set power consumption of an entire on-vehicle network in accordance with a status of the on-vehicle network.SOLUTION: A setting management apparatus comprises: an acquisition section for acquiring configuration information indicating configurations of one or more on-vehicle devices connected to an on-vehicle network and a configuration of the on-vehicle network when updating software of an on-vehicle device connected to the on-vehicle network; a decision section for executing simulations of operations of the one or more on-vehicle devices after the software update based on the configuration information acquired by the acquisition section and decides whether or not the operations of the one or more on-vehicle devices after the update of the software are established; and a determination section for determining setting information of the one or more on-vehicle devices after the update of the software based on power consumption due to the operations of the one or more on-vehicle devices decided to be established by the decision section.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] The present disclosure relates to a setting management device, a setting management method, and a setting management program. [Background technology]

[0002] Vehicles are equipped with a variety of on-board devices, including control ECUs (Electronic Control Units) that control the engine, transmission, etc., body ECUs that control headlights, power windows, etc., and information 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 consumption operation and high-processing capacity operation depending on the operating state of the vehicle. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] International Publication No. 2016 / 111213 Summary of the Invention [Problem to be solved by the invention]

[0005] 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. [Means for solving the problem]

[0006] A setting management device according to one embodiment of the present disclosure includes 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 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 of 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.

[0007] 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. [Effects of the Invention]

[0008] According to the present disclosure, the power consumption of the entire in-vehicle network can be set according to the state of the in-vehicle network. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 is a block diagram showing an example of the configuration of an in-vehicle system according to an embodiment. [Figure 2] FIG. 2 is a block diagram illustrating an example of a hardware configuration of a server according to the embodiment. [Figure 3] FIG. 3 is a functional block diagram illustrating an example of the functions of the server according to the embodiment. [Figure 4] FIG. 4 is a diagram illustrating an example of the configuration of the vehicle information database. [Figure 5A]FIG. 5A is a diagram showing an example of a part of the configuration of the ECU database, and is a diagram showing a first table. [Figure 5B] 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. [Figure 6] FIG. 6 is a sequence diagram showing an example of in-vehicle network setting management in the setting management system according to the embodiment. [Figure 7] FIG. 7 is a flowchart illustrating an example of the setting management process. DETAILED DESCRIPTION OF THE INVENTION

[0010] <Summary of Embodiments of the Present Disclosure> The following provides an outline of embodiments of the present disclosure.

[0011] (1) A setting management device according to this embodiment includes: 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 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 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 valid by the determination unit. 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.

[0012] (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 depending on whether the operation state of the simulation result satisfies the condition for establishment.

[0013] (3) In the above (2), the condition for satisfying the requirement may include a transmission time of the data from a data source to a destination. This makes it possible to determine whether the operation of one or more in-vehicle devices is possible depending on whether the end-to-end transmission time of the data is equal to or shorter than the required transmission time included in the condition for satisfying the requirement.

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

[0015] (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 each of 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.

[0016] (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 makes it possible to set the one or more in-vehicle devices under the operating condition that has the lowest power consumption.

[0017] (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.

[0018] (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.

[0019] (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.

[0020] (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.

[0021] (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.

[0022] (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, thereby eliminating the need to communicate with an external device for the setting information, and enabling the setting information to be provided to the in-vehicle device without being affected by communication conditions with the outside of the vehicle.

[0023] (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 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] (14) A setting management program according to this 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.

[0025] <Details of the embodiment of the present disclosure> DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, the preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. At least some of the following preferred embodiments may be combined in any desired manner.

[0026] [1. In-vehicle systems] 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 a 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] The 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 the various parts of the vehicle, and detect or monitor the state of the hardware of the various parts of the vehicle, the state of the environment 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 "in-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 400A. are connected to bus 400B. For example, bus 400A is an information system bus, and ECU 300E of the information system is connected to 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-type 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-mentioned 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 update of the application software is necessary. Communication of the application software includes changing (changing at least a part of) the functions realized by the application software, 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"). The ECU DB 600 and the vehicle information DB 700 will be described in detail later.

[0038] [2. Server hardware configuration] 2 is a block diagram showing an example of a 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, for example, a semiconductor memory such as an SRAM (Static Random Access Memory) or a DRAM (Dynamic Random Access Memory). The nonvolatile memory 502 is, for example, 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 setting management program 510 being executed by the processor 501. 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 conforming to 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 ECUDB 600 and the vehicle information DB 700.

[0044] [3. Server Functions] FIG. 3 is a functional block diagram illustrating an example of the 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 ECUDB 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 ECUDB 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 one database. In this case, the acquisition unit 511 acquires the ECU configuration information and the NW configuration information from one database.

[0048] Fig. 4 is a diagram showing an example of the configuration of a 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 sub-networks for each communication line, and the NW configuration information includes configuration information about each sub-network.

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

[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 Figure 4, bus 400A as a communication line corresponds to a transmission speed of 500 kbps, which is the CAN setting for bus 400A. Bus 400B as a communication line corresponds to a transmission speed of 5 Mbps, which is the CAN FD setting for bus 400B. Bus 400C as a communication line corresponds to a transmission speed of 5 Mbps, which is the CAN FD setting for 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 "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 "number of used cores: "1" or "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 type.

[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 yet 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 a 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 in 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 (e.g., 10 ms to 65,000 ms) of the communication cycle of data of the data type "brake" is specified as the operating condition. That is, the operating conditions of the ECU include multiple items (such as the clock frequency, the number of used cores, and the data communication cycle), and the construction unit 512 can specify multiple combinations of values ​​of the multiple items. In a specific example, the construction unit 512 sequentially sets, in the simulation model 520, each of multiple operating conditions for all combinations of values ​​of the multiple items.

[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 uses the simulation model 520 in which one of a plurality of operating conditions is set to simulate the operation of the in-vehicle system 10 under the operating condition. When the simulation of the operation of the in-vehicle system 10 under one operating condition is completed, the determination unit 513 performs a simulation of 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 the 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 and output to 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 in the simulation in association with the operating conditions. The state information includes, for example, the transmission time from the data source to the destination, the data retention time in the relay ECU 200, and the data communication cycle.

[0062] The determination unit 513 determines whether the operation of the in-vehicle system 10 after the update of the application software 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 update of the application software 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 or not the state information satisfies the condition to be met.

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

[0065] For example, the conditions to be met 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 sent and received by a control system ECU (control system data) cannot tolerate delays of more than a certain amount (e.g., delays exceeding 100 μs). On the other hand, data sent and received by an information system ECU (information system data) can tolerate a longer delay time (e.g., delays up to 1 ms). The conditions to be met include a condition for the transmission time from the source 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 for each item if the values ​​included in the status information for all items satisfy the condition for each item. The determination unit 513 determines that the status information does not satisfy the condition for each item if the value included in the status information for at least one item does not satisfy the condition for each item. 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 each item 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 each item 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 smallest calculated power consumption from among a plurality of operating conditions that satisfy the establishment condition. For example, if there is one operating condition that satisfies the establishment condition, 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 each of the ECU 300, the relay ECU 200, and the external communication device 350 under the operating conditions with the smallest 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. Configuration Management System Operation] FIG. 6 is a sequence diagram showing an example of in-vehicle network setting management in the setting management system according to the embodiment.

[0073] When update software for one application software is stored in the server 500, which is an OTA server, it becomes possible to update the application software in the ECU. The server 500 transmits update availability information notifying that the application software is updateable 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, S2_2).

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

[0075] Relay ECU 200, which has received the request for software update from ECU 300A, requests server 500 for software update (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, S6_2). Each of the ECU 300 and external communication device 350 transmits its own ECU information to the relay ECU 200 (steps S7_1, 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 is updated (step S101). In step S101, for example, the processor 501 can acquire the ECU configuration information from the ECUDB 600 and acquire 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 by 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 state information of the virtual in-vehicle system 10 after the application software is updated.

[0084] Processor 501 determines whether the generated state information satisfies the condition to be met (step S105).

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

[0086] The processor 501 determines whether all the operating conditions have been selected (step S107). If there are any unselected operating conditions remaining (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] 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 nonvolatile 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 setting 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, the relay ECU 200 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 update of the application software, the one or more ECUs do not change their settings.

[0094] [5. Variation example] 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 update availability 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 Notes] The embodiments disclosed herein are illustrative in all respects and are not restrictive. The scope of the present invention is defined by the claims rather than the above-described embodiments, and includes meanings equivalent to the claims and all modifications within the scope thereof. [Explanation of symbols]

[0098] 10 In-Vehicle Systems 20 Configuration Management System 100 In-Vehicle Network 200 Relay ECU (on-board device) 300,300A,300B,300C,300D,300E ECU (vehicle equipment) 350 External communication device 400A, 400B, 400C buses 500 servers (settings management devices) 501 processor 502 Non-volatile memory 503 Volatile Memory 504 Communication Interface (Communication I / F) 505 Bus 510 Configuration Management Program 511 Acquisition Department 512 Construction Department 513 Judgment section 514 Calculation Unit 515 Decision Section 516 Output section 520 Simulation Model 600 ECU database (ECUDB) 600A Table 1 600B Second Table 700 Vehicle Information Database (Vehicle Information DB)

Images