Electronic control device, management method of power supply, and management program for power supply

Abstract

To appropriately reduce power consumption while maintaining security and safety by virtualizing an application.SOLUTION: An ECU 1 includes a plurality of control units 2 to 5, and a plurality of memory blocks 11 to 14 respectively corresponding to each of the plurality of control units. On any of the plurality of control units, a plurality of virtualized applications can be operated. The ECU includes a management unit 6 which stops power supply to a control unit in which all the corresponding applications are stopped, and stops power supply to a memory block corresponding to a control unit to which the power supply is stopped.SELECTED DRAWING: Figure 12

Description

[Technical Field]

[0001] The present invention relates to an electronic control device, a power supply management method, and a power supply management program. [Background technology]

[0002] A vehicle is equipped with multiple electronic control units (hereinafter referred to as ECUs (Electronic Control Units)). For example, with the introduction of advanced driver-assistance systems (ADAS (Advanced Driver-Assistance Systems)) and other technologies, the number of ECUs installed in a vehicle is on the rise. Furthermore, close cooperation between ECUs prepared for different functions, such as powertrain, body, and chassis, is becoming necessary. Against this background, integrating the functions of multiple ECUs that were previously installed for different functions into a specific ECU is being considered. For example, Patent Document 1 discloses a technology that uses virtualization technology to virtualize the applications that realize the functions of each ECU and integrate the functions of various ECUs. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Publication No. 2022-99044 Summary of the Invention [Problem to be solved by the invention]

[0004] While application virtualization can ensure security and safety, it also comes with the problem of reduced energy efficiency and increased power consumption.In particular, in automotive environments, where battery constraints are strict, the impact of increased power consumption is significant, making it necessary to reduce power consumption.

[0005] The present invention has been made in consideration of the above-mentioned circumstances, and its purpose is to provide an electronic control device, a power supply management method, and a power supply management program that can appropriately reduce power consumption while ensuring security and safety by virtualizing apps. [Means for solving the problem]

[0006] According to the electronic control device of claim 1, the electronic control device includes a plurality of control units (2 to 5) and a plurality of memory blocks (11 to 14) corresponding to the plurality of control units, and a plurality of virtualized applications can run on any of the plurality of control units. The electronic control device includes a management unit (6) that stops the power supply to a control unit among the plurality of control units in which all of the corresponding applications have been stopped, and stops the power supply to the memory block corresponding to the control unit for which the power supply has been stopped.

[0007] When all apps are stopped on one of the multiple control units, the power supply to the control unit where all apps are stopped is stopped, and the power supply to the memory block corresponding to the control unit whose power supply is stopped is stopped. By virtualizing apps, security and safety are ensured, while power consumption can be appropriately reduced by stopping the power supply to control units and memory blocks that are not involved in the execution of apps. [Brief explanation of the drawings]

[0008] [Figure 1] A functional block diagram showing the overall configuration of one embodiment. [Figure 2] A diagram showing an example of the execution state of an app [Figure 3] Diagram showing the application management table [Figure 4] Figure showing the core management table [Figure 5] FIG. 1 shows a mobility management table. [Figure 6] FIG. 10 is a diagram showing a destination candidate management table. [Figure 7] flowchart [Figure 8] flowchart [Figure 9] FIG. 1 shows a mobility management table. [Figure 10] FIG. 10 is a diagram showing a destination candidate management table. [Figure 11] A diagram showing the relationship between processing power, operating clock, and power consumption [Figure 12] Diagram explaining app relocation [Figure 13] A diagram explaining the stopping of power supply to the core and memory block DETAILED DESCRIPTION OF THE INVENTION

[0009] Hereinafter, embodiments will be described with reference to the drawings. As shown in FIG. 1, ECU1 is mounted on a vehicle such as an automobile, and performs control of devices mounted on the vehicle, control of communications with the outside of the vehicle, and information processing related to driving control such as autonomous driving. ECU1 has a multi-core configuration including cores 2 to 5 (corresponding to a control unit). A core is synonymous with a processor element, and in FIG. 1, core 2 is illustrated as "PE0," core 3 as "PE1," core 4 as "PE2," and core 5 as "PE3." In this embodiment, an example in which the number of cores is "4" is illustrated, but the number of cores is not limited to "4."

[0010] The ECU 1 includes a hypervisor 6 (corresponding to a management unit) as a component of functions realized by executing a program. The hypervisor 6 can execute multiple applications in parallel on virtual drivers 7 to 10 corresponding to the cores 2 to 5, respectively. The multiple applications executed on the virtual drivers 7 to 10 are virtualized control software. The multiple applications executed on the virtual driver 7 by the core 2 are referred to as "VM0-1," "VM0-2," ..., "VM0-n." The multiple applications executed on the virtual driver 8 by the core 3 are referred to as "VM1-1," "VM1-2," ..., "VM1-n." The multiple applications executed on the virtual driver 9 by the core 4 are referred to as "VM2-1," "VM2-2," ..., "VM2-n." ​​The multiple applications executed on the virtual driver 10 by the core 5 are referred to as "VM3-1," "VM3-2," ..., "VM3-n," where "n" is a natural number. These applications can be executed by moving the virtual drivers, as described below. The hypervisor 6 executes a power supply management method and a power supply management program.

[0011] Cores 2 to 5 are assigned usable memory blocks 11 to 14, respectively. In Figure 1, memory block 11 assigned to core 2 is shown as "RAM Block A," memory block 12 assigned to core 3 is shown as "RAM Block B," memory block 13 assigned to core 4 is shown as "RAM Block C," and memory block 14 assigned to core 5 is shown as "RAM Block D." The number of memory blocks corresponds to the number of cores.

[0012] When multiple applications are running on the virtual drivers 7 to 10, the hypervisor 6 manages an application management table indicating the processing load and required RAM capacity for each application, a core management table indicating the processing capacity, power efficiency, and RAM capacity for each core, a migration possibility management table indicating the operating status and migration possibility for each application, and a migration destination candidate management table indicating migration destination candidate for each application.

[0013] 2, for example, a case will be illustrated in which "VM0-1" and "VM0-2" are running on "PE0" by the hypervisor 6, "VM1-1" and "VM1-2" are running on "PE1" by the hypervisor 6, "VM2-1" is running on "PE2" by the hypervisor 6, and "VM3-1" is running on "PE3" by the hypervisor 6. As shown in FIG. 3, for "VM0-1" running on the virtual driver 7, for example, the hypervisor 6 records 2 [MIPS] as the processing load and 10 [KByte] as the required RAM capacity in the application management table.

[0014] 4, the hypervisor 6 records 20 [MIPS] as the processing capacity, 2 [MIPS / W] as the power efficiency, and 50 [KByte] as the RAM capacity for, for example, core 2 in the core management table. In this embodiment, a fixed value is used as the power efficiency, but a table or formula in which the power efficiency changes depending on the frequency of the operating clock may also be used, as shown in FIG. 11, which will be described later.

[0015] 5, for example, for "VM0-1" being executed on "PE0" by the hypervisor 6, the hypervisor 6 records "in operation" as the operating state in the mobility management table, and records "not movable", indicating that there is a restriction on movement, as the mobility possibility. For example, for "VM0-2" being executed on "PE0" by the hypervisor 6, the hypervisor 6 records "in operation" as the operating state, and records "possible to be migrated", indicating that it can be an application to be migrated, as the mobility possibility.

[0016] 6, the hypervisor 6 records in the migration destination candidate management table that, for example, for "VM0-1" being executed on "PE0" by the hypervisor 6, "PE1," "PE2," and "PE3" are not migration destination candidates. For example, for "VM0-2" being executed on "PE0" by the hypervisor 6, the hypervisor 6 records that "PE1," "PE2," and "PE3" are migration destination candidates.

[0017] The hypervisor 6 updates the application management table, the core management table, the migration possibility management table, and the migration destination candidate management table, and determines whether the execution states of the plurality of applications on the virtual drivers 7 to 10 have changed.

[0018] This section explains how to move an application. When moving an application, the allocation between the physical driver and the virtual driver is changed. The allocation of application time slots is also changed according to differences in the operating clocks of cores 2 to 5. Furthermore, if the latency of interrupt responses changes due to a change in the combination of applications running on the same core, the amount of buffer RAM allocated to the virtual driver is increased or decreased to absorb the changing latency.

[0019] Since moving an app temporarily stops the app, it is desirable to manage apps that can be moved and impose restrictions on the movement of the apps. For example, apps related to vehicle operation, stopping, steering, etc., such as an app that controls engine operation, an app that controls meter display, and an app that controls airbag operation, may be restricted from moving. On the other hand, apps not related to vehicle operation, such as an app that controls air conditioner operation, an app that controls music playback, and an app that controls software updates not related to vehicle control, may not be restricted from moving. Furthermore, apps undergoing software verification in shadow mode may be restricted from moving in consideration of the need to maintain verification conditions. Furthermore, apps that control power supply may be restricted from moving in preparation for emergencies, such as disasters.

[0020] Next, the operation of the above-described configuration will be described with reference to FIGS. The hypervisor 6 waits for the establishment of a start event of a change determination process that determines a change in the execution state of an application. The hypervisor 6 monitors the establishment of the start event of the change determination process, and when it identifies the establishment of the start event of the change determination process due to, for example, a change in a use case, a degradation of a function, or a change in the vehicle state from running to stopped, the hypervisor 6 starts the change determination process.

[0021] When the hypervisor 6 starts the change determination process, it updates the application management table, core management table, migration possibility management table, and migration destination candidate management table (S1) and checks whether the number of options for relocating applications has increased. The hypervisor 6 determines whether any applications have been stopped (S2). If the hypervisor 6 determines that any applications have been stopped (S2: YES), it calculates the power consumption of the entire system when the applications are relocated based on the updated information (S7). In this case, if there are multiple possible patterns for relocating applications, the hypervisor 6 calculates the power consumption of the entire system when the applications are relocated for all of the multiple patterns.

[0022] If the hypervisor 6 determines that no applications have been stopped (S2: NO), it determines whether the number of applications that can be moved has increased (S3). If the hypervisor 6 determines that the number of applications that can be moved has increased, for example, because the vehicle has transitioned from a running state to a stopped state or a parked state (S3: YES), it also calculates the power consumption of the entire system when the applications are relocated based on the updated information (S7).

[0023] If the hypervisor 6 determines that the number of apps that can be moved has not increased (S3: NO), it determines whether the processing load of the apps has decreased (S4). If the hypervisor 6 determines that the processing load of the apps has decreased (S4: YES), it also calculates the power consumption of the entire system when the apps are relocated based on the updated information (S7).

[0024] If the hypervisor 6 determines that the processing load of the application has not decreased (S4: NO), it determines whether the RAM usage has decreased (S5). If the hypervisor 6 determines that the RAM usage has decreased (S5: YES), it also calculates the power consumption of the entire system when the application is relocated based on the updated information (S7).

[0025] If the hypervisor 6 determines that the RAM usage has not decreased (S5: NO), it determines whether the number of candidate destinations for the application has increased (S6). If the hypervisor 6 determines that the number of candidate destinations for the application has increased, for example, due to a change in security or safety constraints (S6: YES), it also calculates the power consumption of the entire system when the application is relocated based on the updated information (S7). Changes in security or safety constraints can occur, for example, when the vehicle transitions from a running state to a stopped or parked state, or when, in a configuration in which the ECU 1 can communicate data with a center device via a communication network, it transitions from a state in which data communication is possible due to a connection of a data communication line to a standalone state in which data communication is not possible due to a disconnection of the data communication line. If the hypervisor 6 determines that the number of candidate destinations for the application has not increased (S7: NO), it ends the change determination process and waits for the establishment of the next start event for the change determination process.

[0026] The hypervisor 6 calculates the power consumption of the entire system when the application is relocated based on the updated information, and compares the calculated power consumption with the current power consumption of the entire system to determine whether the power consumption of the entire system can be reduced (S8). Here, if it is possible to derive a core on which an application is not executed as a result of the relocation of the application, that is, if it is possible to reduce the number of cores on which the application is executed, it is possible to reduce the power consumption of the entire system by stopping the power supply to that core and also stopping the power supply to the memory block corresponding to the core to which the power supply is stopped.

[0027] If the hypervisor 6 determines that it is not possible to derive a core on which the application is not executed, i.e., that it is not possible to reduce the number of executing cores and that it is not possible to reduce the power consumption of the entire system (S8: NO), it terminates the change determination process and waits for the occurrence of the next start event of the change determination process.

[0028] On the other hand, when the hypervisor 6 determines that it is possible to derive a core on which an application is not executed, that is, to reduce the number of execution cores, and thus to reduce the power consumption of the entire system (S8: YES), it identifies a relocation pattern that minimizes the power consumption of the entire system (S9). That is, if there is only one expected relocation pattern, the hypervisor 6 identifies that one expected relocation pattern as the relocation pattern that minimizes the power consumption of the entire system. If there are multiple expected relocation patterns, the hypervisor 6 calculates and compares the power consumption of the entire system for each of the multiple expected relocation patterns, and identifies the relocation pattern with the smallest calculation result as the relocation pattern that minimizes the power consumption of the entire system.

[0029] The hypervisor 6 relocates the application in accordance with the identified relocation pattern (S10), stops the power supply to the relevant core and memory block (S11, corresponding to the power supply stopping procedure), terminates the change determination process, and waits for the occurrence of the start event of the next change determination process.

[0030] Specific examples will be described below with reference to FIGS. 9 to 13. Assume that "VM0-2" (corresponding to the application to be stopped) is stopped from the application execution state shown in FIG. 2. When "VM0-2" is stopped, the hypervisor 6 updates the operation state of "VM0-2" from "running" to "stopped" in the mobility management table shown in FIG. 5, as shown in FIG. 9, and updates the mobility from "possible to move" to "not possible to move." Furthermore, in response to the stopping of "VM0-2," the hypervisor 6 updates the application management table shown in FIG. 3 and the core management table shown in FIG. 4, and updates the mobility of "VM1-2" from "not possible to move" to "possible to move." Furthermore, as shown in FIG. 10, in the migration destination candidate management table shown in FIG. 6, the hypervisor 6 updates "PE0" for "VM1-2" from "not applicable to migration destination candidate" to "approved to migration destination candidate."

[0031] In this state, the hypervisor 6 decides to relocate the applications and calculates the power consumption of the entire system when "VM1-1" (corresponding to the application to be moved) and "VM1-2" (corresponding to the application to be moved) are relocated. In this case, as shown in Fig. 10, "PE0", "PE2", and "PE3" are candidate migration destinations for "VM1-1", and "PE0" is candidate migration destination for "VM1-2". Therefore, the hypervisor 6 calculates the power consumption of the entire system for each of the following relocation patterns: a relocation pattern in which both "VM1-1" and "VM1-2" are migrated to "PE0", a relocation pattern in which "VM1-1" is migrated to "PE2" and "VM1-2" is ... and a relocation pattern in which "VM1-1" is migrated to "PE3" and "VM1-2" is migrated to "PE0".

[0032] Here, as shown in Figure 11, in the case of an asymmetric multi-core system where the processing power curve and power consumption curve differ depending on the core, the increase in power consumption after migration is estimated for each candidate destination, and a relocation pattern that minimizes the power consumption of the entire system is identified.

[0033] When the hypervisor 6 identifies the relocation pattern of migrating "VM1-1" to "PE3" and migrating "VM1-2" to "PE0" as the relocation pattern that minimizes the power consumption of the entire system, it migrates "VM1-1" currently being executed by "PE1" to "PE3" and migrates "VM1-2" currently being executed by "PE1" to "PE0" as shown in FIG. 12. After completing the migration of "VM1-1" and "VM1-2" in this manner, the hypervisor 6 stops the power supply to "PE1" that has been executing "VM1-1" and "VM1-2" and stops the power supply to "RAM Block B" corresponding to "PE1" as shown in FIG. 13. In other words, the hypervisor 6 reduces the power consumption of the entire system by stopping the power supply to "PE1" and "RAM Block B."

[0034] The above describes the case where "VM0-2" is stopped from the application execution state shown in Figure 2, but the same applies when another application is stopped. Furthermore, when specifying a relocation pattern, it is not necessary to specify a relocation pattern that minimizes the power consumption of the entire system. For example, if there are an extremely large number of expected relocation patterns, the power consumption of the entire system may be calculated for only some of the relocation patterns.

[0035] As described above, according to this embodiment, the following advantageous effects can be obtained. In ECU 1, when all applications are stopped on any one of the multiple cores 2 to 5, power supply to the core to which all applications are stopped is stopped, and power supply to the memory block corresponding to the core to which power supply is stopped is stopped. By virtualizing applications, security and safety are ensured, while power supply to cores and memory blocks not involved in the execution of applications is stopped, thereby appropriately reducing power consumption.

[0036] When an app is stopped as an app to be stopped, another app other than the app to be stopped is moved as an app to be moved. By moving the app to be moved, cores and memory blocks not involved in the execution of the app can be derived, the number of cores and memory blocks not involved in the execution of the app can be reduced, and the power supply to cores and memory blocks not involved in the execution of the app can be stopped.

[0037] The destination of the application to be migrated is determined based on the power efficiency characteristics of each core. By determining the destination of the application while taking into account the power consumption of the entire system, it is possible to prevent the power consumption of the entire system from increasing after the application is migrated.

[0038] By managing apps that can be moved, for example, apps that are involved in driving, stopping, steering, etc. of the vehicle can be restricted from moving, and apps that are not involved in driving, stopping, steering, etc. of the vehicle can be allowed to move without restrictions, thereby preventing problems caused by moving apps.

[0039] Although the present disclosure has been described with reference to the embodiments, it is understood that the present disclosure is not limited to the embodiments or structures. The present disclosure also encompasses various modifications and modifications within the scope of equivalents. In addition, various combinations and forms, as well as other combinations and forms including only one element, more than one element, or less than one element, are also within the scope and spirit of the present disclosure.

[0040] In this embodiment, the number of memory blocks is equal to the number of cores, but the number of memory blocks may be greater than the number of cores, i.e., multiple memory blocks may be allocated to one core. In this case, the allocation of memory blocks may be changed in response to changes in the required RAM capacity due to, for example, the movement of applications.

[0041] The control unit and the method described herein may be implemented by a special-purpose computer configured by configuring a processor and memory programmed to perform one or more functions embodied in a computer program. Alternatively, the control unit and the method described herein may be implemented by a special-purpose computer configured by configuring a processor with one or more dedicated hardware logic circuits. Alternatively, the control unit and the method described herein may be implemented by one or more special-purpose computers configured by combining a processor and memory programmed to perform one or more functions with a processor configured with one or more hardware logic circuits. Furthermore, the computer program may be stored as instructions executed by a computer on a computer-readable non-transitory tangible storage medium. [Explanation of symbols]

[0042] In the drawing, 1 is an electronic control device, 2 to 5 are cores (control units), 6 is a hypervisor (management unit), and 11 to 14 are memory blocks.

Claims

1. An electronic control device (1) comprising a plurality of control units (2 to 5) and a plurality of memory blocks (11 to 14) corresponding to each of the plurality of control units, wherein a plurality of virtualized applications can run on any of the plurality of control units, An electronic control device comprising a management unit (6) that stops the power supply to a control unit among the plurality of control units when all corresponding apps are stopped, and stops the power supply to the memory block corresponding to the control unit for which the power supply is stopped.

2. The electronic control device according to claim 1 , wherein when the management unit stops any one of the applications as an application to be stopped, the management unit moves an application other than the application to be stopped as an application to be moved.

3. The electronic control device according to claim 2 , wherein the management unit determines a destination of the application to be moved based on a power efficiency characteristic of each of the control units.

4. The electronic control device according to claim 2 , wherein the management unit manages applications that can become the applications to be moved.

5. An electronic control device (1) comprising a plurality of control units (2 to 5) and a plurality of memory blocks (11 to 14) corresponding to each of the plurality of control units, in which a plurality of virtualized applications can run on any of the plurality of control units, A power supply management method that stops the power supply to a control unit among the plurality of control units for which all corresponding apps have been stopped, and executes a power supply stopping procedure that stops the power supply to the memory block corresponding to the control unit for which the power supply is stopped.

6. An electronic control device (1) comprising a plurality of control units (2 to 5) and a plurality of memory blocks (11 to 14) corresponding to each of the plurality of control units, and in which a plurality of applications virtualized on any of the plurality of control units can run, A power supply management program that stops the power supply to a control unit among the plurality of control units for which all corresponding apps have been stopped, and executes a power supply stopping procedure that stops the power supply to the memory block corresponding to the control unit for which the power supply is stopped.

Images