In-vehicle system and control method for in-vehicle system

Abstract

This in-vehicle system includes an information processing device cluster including a first information processing device and a second information processing device capable of communicating with each other. The first information processing device and the second information processing device each include computer hardware and a virtualization platform operating on the computer hardware. The in-vehicle system further includes a controller for causing one or a plurality of virtual machines to operate on the virtualization platforms of the first information processing device and the second information processing device. The controller monitors the usage condition of computer hardware resources in the first information processing device and the second information processing device, and according to the usage condition of the hardware resources, changes the configuration of the one virtual machine or the plurality of virtual machines in real time.

Description

In-vehicle system and method for controlling the in-vehicle system

[0001] This disclosure relates to an in-vehicle system and a control method for the in-vehicle system. This application claims priority to Japanese Application No. 2022-138903, filed September 1, 2023, the entire contents of which are incorporated herein by reference.

[0002] Conventionally, vehicles are equipped with multiple ECUs (Electronic Control Units), which are control devices for controlling various parts of the vehicle. ECUs are essentially computers, so they are capable of interrupt processing and can respond appropriately in emergencies.

[0003] ECUs were originally used to control engines. However, as vehicle equipment becomes more electronic, ECUs are now being used in a variety of places. For example, ECUs are also responsible for processing the information collected from various sensors installed in the vehicle. ECUs are also used to determine the vehicle's driving status, control the brakes, control electrical equipment, and even in lane keeping systems and following distance control systems.

[0004] Meanwhile, the number of processes performed by ECUs in vehicles is increasing at a rate faster than the number of ECUs installed in the vehicle. Therefore, there is a technology that divides these processes into multiple tasks and executes them on multiple ECUs. However, in the case of in-vehicle ECUs, the load of each task varies greatly depending on the situation. Therefore, it is necessary to dynamically distribute the load on the ECUs.

[0005] One proposal for solving these problems is disclosed in Patent Document 1. The technology disclosed in Patent Document 1 provides an ECU that executes a task with a virtual device driver that enables transparent use of an external device. When the task is migrated to another ECU, this virtual device driver is also migrated to the destination ECU. This makes it possible for the destination ECU to transparently use the external device. Note that this migration is performed while the ECU is running. This type of migration is called "live migration." All migrations described in this specification are live migrations, and for the sake of brevity, they will be referred to simply as "migration."

[0006] JP 2009-070135 A JP 2013-003946 A International Publication No. 2021 / 010124

[0007] An in-vehicle system according to a first aspect of this disclosure is an in-vehicle system including an information processing device cluster including a first information processing device and a second information processing device capable of communicating with each other, wherein each of the first information processing device and the second information processing device includes computer hardware and a virtualization platform operating on the computer hardware, and the in-vehicle system further includes a controller for operating one or more virtual machines on the virtualization platform of the first information processing device and the second information processing device, and the controller monitors the usage of computer hardware resources in the first information processing device and the second information processing device, and changes the configuration of the one or more virtual machines in real time according to the usage of the hardware resources.

[0008] The above and other objects, features, aspects and advantages of the present disclosure will become apparent from the following detailed description of the disclosure taken in conjunction with the accompanying drawings.

[0009] FIG. 1 is a block diagram showing an outline of the configuration of an ECU to which virtualization technology is applied. FIG. 2 is a schematic diagram for explaining an ECU cluster. FIG. 3 is a schematic diagram for explaining migration of a virtual ECU in an ECU cluster. FIG. 4 is a block diagram showing an example of the layout of a controller that controls an ECU cluster. FIG. 5 is a block diagram showing another example of the layout of a controller that controls an ECU cluster. FIG. 6 is a schematic diagram showing an example of the contents of a configuration file for specifying an operating destination used in the embodiment. FIG. 7 is a schematic diagram showing an example of the contents of a priority configuration file used in the embodiment. FIG. 8 is a schematic diagram showing an example of the contents of a configuration file for specifying initial resources used in the embodiment. FIG. 9 is a schematic diagram for explaining migration of a virtual machine between different ECUs. FIG. 10 is a schematic diagram for explaining reduction of used resources (expansion of available resources) in a single ECU. FIG. 11 is a block diagram showing the hardware configuration of an in-vehicle system and an ECU according to the present disclosure. FIG. 12 is a flowchart showing the control structure of a program for resource management executed by a controller of the in-vehicle system according to the embodiment. Fig. 13 is a flowchart showing a control structure of a computer program for implementing the processing for starting up a virtual machine shown in Fig. 12. Fig. 14 is a flowchart showing a control structure of a computer program for implementing the processing for optimizing resources shown in Fig. 12. Fig. 15 is a flowchart showing a control structure of a computer program for implementing the migration shown in Fig. 14. Fig. 16 is a flowchart showing a control structure of a computer program for implementing the resource reduction processing shown in Fig. 14.

[0010] [Problem to be Solved by This Disclosure] With recent advances in computer technology, it has become possible to build a virtualization platform on a single ECU and run multiple virtual machines on this virtualization platform, each using an independent OS (Operating System), BSW (Basic Software), etc. In other words, one or multiple virtual ECUs can be run on a single ECU. As a result, the large number of ECUs used in a vehicle can be consolidated into a relatively small number of ECUs. However, even when multiple virtual machines are run on such a relatively small number of ECUs, it is necessary to dynamically distribute the load on each ECU.

[0011] The technology disclosed in Patent Document 1 involves load balancing at the task level of an application. When the technology disclosed in Patent Document 1 is applied to an ECU on which a virtual machine is running, the load is distributed among multiple virtual ECUs running on that ECU. However, such a method cannot reduce the load on the ECU on which the virtual machine is running. This problem can occur not only in ECUs but also in multiple information processing devices installed in a vehicle.

[0012] An object of this disclosure is to provide an in-vehicle system and a control method that can dynamically control the load on an information processing device on which a virtual machine is running.

[0013] [Advantages of the Disclosure] As described above, according to the disclosure, it is possible to provide an in-vehicle system and a control method that can dynamically control the load on an information processing device on which a virtual machine is running.

[0014] [Description of the embodiments of the present disclosure] This disclosure can be summarized as follows.

[0015] (1) An in-vehicle system according to a first aspect of this disclosure is an in-vehicle system including an information processing device cluster including a first information processing device and a second information processing device that are capable of communicating with each other, each of the first information processing device and the second information processing device including computer hardware and a virtualization platform operating on the computer hardware, and the in-vehicle system further includes a controller for operating one or more virtual machines on the virtualization platform of the first information processing device and the second information processing device, and the controller monitors the usage of hardware resources in the first information processing device and the second information processing device and changes the configuration of the one or more virtual machines in real time according to the usage of the hardware resources.

[0016] A first information processing device and a second information processing device are separately provided in one information processing device cluster. A controller operates one or more virtual machines in each of these information processing devices. The controller monitors the usage status of hardware resources in the first information processing device and the second information processing device, and changes the configuration of the virtual machines in real time according to the usage status of the hardware resources. As a result, the load of the information processing device on which the virtual machine is running can be dynamically controlled. This load control can be performed independently of the load control in other information processing device clusters, making it easy to dynamically control the load of the virtual machines in the in-vehicle system.

[0017] (2) In (1) above, the controller may include a controller device that is capable of communicating with a first information processing device and a second information processing device included in the information processing device cluster and that is provided independently of the first information processing device and the second information processing device.

[0018] The controller device is provided independently of both the first information processing device and the second information processing device, and functions as a controller. As a result, the controller device is not affected by dynamic control of the load of the information processing device, and dynamic control of the load of the information processing device for executing the virtual machine in the in-vehicle system can be stably performed.

[0019] (3) In the above (1), the controller may include a virtual controller executed on a virtualization platform of the first information processing device.

[0020] The controller is realized as a virtual controller in the virtualization platform of the first information processing device. This eliminates the need for separate hardware for executing the controller, making it possible to keep costs for the in-vehicle device low and facilitating maintenance.

[0021] (4) In any one of (1) to (3) above, the controller may include a placement configuration recording unit that records placement configuration information that specifies the placement configuration of one or more virtual machines, and a placement control unit that monitors the operating status of the first information processing device and the second information processing device, and determines in real time the placement of one or more virtual machines within the information processing device cluster so that the one or more virtual machines operate stably, and changes it if necessary.

[0022] The virtual machine placement configuration is provided separately from the placement control unit. When changing the placement of the virtual machines, it is only necessary to change the recorded contents of the placement configuration unit, and there is no need to change the function of the placement control unit. As a result, the virtual machine placement configuration can be easily changed.

[0023] (5) In (4) above, the deployment configuration information may include, for one or more virtual machines, operation destination designation information that records a virtual machine to be operated on a specific information processing device that is the operation destination and information that designates the specific information processing device that is the operation destination; priority information that designates a priority when allocating hardware resources for one or more virtual machines; initial resource information that designates the initial allocation of hardware resources when one or more virtual machines are started; or at least any two of the operation destination designation information, priority information, and initial resource information.

[0024] When using the operation destination designation information, for example, it is possible to prevent a virtual machine that needs to be operated on a specific information processing device from being moved to another information processing device. When using the priority information, hardware resources are preferentially allocated to virtual machines that are more important to the in-vehicle system. As a result, the in-vehicle system can stably provide predetermined functions. When using the initial resource information, it is possible to quickly determine the placement of virtual machines when the in-vehicle system is started up. There is no need to adjust the placement of virtual machines after start-up, and the time required to start up the in-vehicle system can be shortened.

[0025] (6) In (4) above, the deployment configuration information may include destination designation information that records, for one or more virtual machines, virtual machines to be run on a specific destination information processing device and information specifying the specific destination information processing device, and priority information that specifies a priority when allocating hardware resources for one or more virtual machines, and the priority may include a first priority that is the highest and a second priority that is lower than the first priority.The deployment control unit may include a destination control unit that monitors the usage of hardware resources on the first information processing device and, in response to detection of a hardware resource shortage on the first information processing device, selects a virtual machine from the virtual machines running on the first information processing device that is indicated by the destination designation information to be movable to the second information processing device and has a second priority, and moves it to the second information processing device.

[0026] When a hardware resource shortage is detected in the first information processing device, the virtual machine migrated from the first information processing device to the second information processing device is one that can be migrated to the second information processing device and is assigned the second priority. This eliminates the possibility that a virtual machine that is important for realizing the functions of the in-vehicle system will be migrated to an information processing device that cannot fully perform those functions, and allows the in-vehicle system to stably perform the functions required for the in-vehicle system.

[0027] (7) In the above (6), the placement control unit may further include a resource reduction unit that monitors the usage status of hardware resources in the first information processing device and the second information processing device, and in response to detection of hardware resource congestion in the in-vehicle system even after the virtual machine migration process by the operation destination control unit, reduces the allocation of hardware resources to a virtual machine with a second priority among the virtual machines running on the information processing device in which hardware resource congestion has been detected.

[0028] In some cases, a hardware resource shortage may be detected even after a virtual machine has been migrated, or the virtual machine may not be able to be migrated, preventing the hardware resource shortage from being resolved. In such cases, the information processing device in which the hardware resource shortage is detected reduces the allocation of hardware resources to virtual machines with low priority. As a result, the amount of hardware resources available to virtual machines with high priority increases, allowing the performance of the in-vehicle system to be maintained.

[0029] (8) In any one of (1) to (7) above, the in-vehicle system may include a plurality of information processing device clusters.

[0030] Even when multiple information processing device clusters are provided, dynamic distribution of the load of the information processing devices for executing virtual machines in each information processing device cluster can be performed independently. As a result, even if the number of virtual machines and information processing devices used in the entire in-vehicle device increases, the functionality of the in-vehicle system can be maintained stably.

[0031] (9) A control method for an in-vehicle system according to a second aspect of this disclosure is a control method for an in-vehicle system including an information processing device cluster including a first information processing device and a second information processing device that can communicate with each other, wherein each of the first information processing device and the second information processing device includes computer hardware and a virtualization platform operating on the computer hardware, and the control method includes the steps of: a computer running one or more virtual machines on the virtualization platform of each of the first information processing device and the second information processing device; a computer monitoring the usage status of hardware resources in the first information processing device and the second information processing device; and a step of changing the configuration of the one or more virtual machines in real time in response to detection of hardware resource congestion in the first information processing device.

[0032] A first information processing device and a second information processing device are separately provided in one information processing device cluster. A computer operates one or more virtual machines on each of these information processing devices. The computer monitors the usage of hardware resources in the first information processing device and the second information processing device, and changes the configuration of the virtual machines in real time according to the usage of the hardware resources. As a result, the load on the information processing device on which the virtual machine is running can be dynamically controlled. This load control can be performed independently of load control in other information processing device clusters, making it easy to dynamically control the load on the virtual machines in the in-vehicle system.

[0033] [Details of the embodiments of the present disclosure] Specific examples of an in-vehicle system and a control method thereof according to embodiments of the present disclosure will be described below with reference to the drawings. In the following description and drawings, the same components are designated by the same reference numerals. Therefore, detailed descriptions thereof will not be repeated. Note that the present disclosure is not limited to these examples, but is defined by the claims, and is intended to include all modifications within the meaning and scope equivalent to the claims. In addition, any one or more of the features of the following embodiments may be combined.

[0034] 1 shows a schematic configuration of an ECU 42 according to a first embodiment of the present disclosure. Referring to FIG. 1, the ECU 42 includes a physical hardware layer 60 including computer hardware, a virtualization infrastructure layer 62 constructed on the physical hardware layer 60, and a virtual machine layer 64 including one or more virtual machines (virtual ECUs) that operate on the virtualization infrastructure layer 62. The virtualization infrastructure layer 62 uses hardware resources referred to as the physical hardware layer 60.

[0035] Each virtual ECU executes the same tasks as each conventional ECU. Each virtual ECU operates in the same virtual operating environment as the conventional operating environment, provided by the virtualization infrastructure layer 62. Therefore, the OS and applications executed by the virtual ECU are the same as those executed by a conventional single ECU.

[0036] B. ECU Cluster As shown in Figure 1, multiple virtual ECUs can be operated by one ECU. However, when multiple virtual ECUs are operated on each ECU, the load on a specific ECU may become excessive. This situation must be avoided.

[0037] To avoid such problems, this embodiment introduces the concept of an ECU cluster. An ECU cluster is a group of multiple ECUs, each of which operates one or more virtual ECUs. As described below, the ECU cluster defines the range of destinations for virtual ECUs when migrating (moving) them. That is, a virtual ECU operating on an ECU in one ECU cluster can be migrated to another ECU in the same ECU cluster, but cannot be migrated to an ECU in another ECU cluster. A controller is provided in the ECU cluster constructed in this way to monitor the resource usage of each ECU in the ECU cluster, thereby leveling the load on each ECU in the cluster and reducing the load on each ECU. By providing an ECU cluster, the number of ECUs and virtual ECUs managed by a single controller can be relatively reduced, resulting in easier management and faster processing.

[0038] It is also possible to avoid excessive load situations by increasing the scale and performance of individual ECUs without using ECU clusters. An example based on this concept is shown in the upper part of Figure 2 as ECU 100. In this example, multiple virtual machines are run on ECU 100. On the other hand, an example based on the concept of ECU clusters is shown in the lower part of Figure 2. In the format shown in the lower part of Figure 2, an ECU cluster is formed with multiple ECUs (e.g., a first ECU 110 and a second ECU 112) that are smaller in scale and have lower performance than ECU 100 shown in the upper part. Multiple virtual ECUs run on each of the first ECU 110 and the second ECU 112. Although the performance of these ECUs is inferior to that of ECU 100, adopting an ECU cluster such as that shown in the lower part of Figure 2 can provide computational resources equivalent to those provided in the upper part of Figure 2.

[0039] However, it is desirable to adopt the configuration shown in the lower part of Figure 2 for an actual vehicle. The reason for this is as follows. As described above, the configuration shown in the upper part of Figure 1 makes it impossible to migrate a virtual ECU to another ECU when the resources of the ECU 100 become constrained. In contrast, the configuration shown in the lower part of Figure 2 allows migration of a virtual ECU between ECUs belonging to the same ECU cluster. Furthermore, when products of the same specification are used for the first ECU 110 and the second ECU 112, the number of ECUs can be adjusted according to the performance requirements of the vehicle. This prevents cost increases due to the use of ECUs with excessive performance. Furthermore, there is an advantage in that mass production costs reduce the unit procurement cost of ECUs, resulting in reduced vehicle manufacturing costs.

[0040] FIG. 3 illustrates migration in the configuration shown in the lower part of FIG. 2 . Referring to FIG. 3 , the in-vehicle ECU cluster 140 includes a first ECU 150 and a second ECU 152. The first ECU 150 and the physical hardware layer 170 can communicate with each other via an in-vehicle network (not shown). For example, as shown on the left side of FIG. 3 , when the resources of the first ECU 150 become constrained, if the resources of the second ECU 152 are available, one of the virtual ECUs running on the first ECU 150 is migrated 176 to the second ECU 152. By migrating the virtual ECU, the first ECU 150 has more resources available, allowing the other virtual ECUs running on the first ECU 150 to maintain stable operation. In other words, problems with the operation of the virtual ECUs due to resource constraints can be prevented.

[0041] To perform this migration, the state of the virtual ECU (such as the contents of memory and virtual registers) must also be transferred from the first ECU 150 to the second ECU 152. In this embodiment, instead of transferring this state information at the time of migration, a synchronization processing unit 154 is provided to constantly synchronize the storage contents of the physical hardware layer 170 of the second ECU 152 with the storage contents of the physical hardware layer 172 of the second ECU 152. This allows the virtual ECU to continue operating even when migration occurs, because the pre-migration state information is stored in the physical storage. As will be described later, some virtual ECUs do not undergo migration because they have a designated ECU as their operating destination or are assigned a high priority for resource allocation. This synchronization processing is not required for such virtual ECUs.

[0042] In this embodiment, a controller is provided in one vehicle ECU cluster for synchronization processing of status information by the synchronization processing unit 154, monitoring of resource usage of the physical hardware layers 170 and 172 in the first ECU 150 and the second ECU 152, and execution of migration.

[0043] FIG. 4 shows a first example of the arrangement of controllers. Referring to FIG. 4, this in-vehicle system 200 includes a first ECU 220 and a second ECU 224 that can communicate with each other via an in-vehicle network 222. Of these, the first ECU 220 is connected to, for example, a sensor 230. The second ECU 224 is connected to a device different from the first ECU 220, such as a vehicle body control signal line 232. The first ECU 220 is provided with a controller 240 that dynamically controls the configuration of the virtual ECUs in the in-vehicle system 200. The controller 240 operates as a virtual machine, similar to other virtual ECUs. In other words, the controller 240 can be called a virtual controller.

[0044] There are certain restrictions on the dynamic control of the configuration of the virtual ECU by the controller 240. For example, the first ECU 220 is connected to the sensors 230, etc. Therefore, the virtual ECUs running tasks for processing information from the sensors 230, etc. must reside on the first ECU 220 and cannot be migrated to the second ECU 224. Similarly, the second ECU 224 is connected to a vehicle body control signal line 232, etc. Therefore, the tasks for controlling the vehicle body must function on the virtual ECUs running on the second ECU 224 and cannot be migrated to the first ECU 220.

[0045] The controller 240 has a storage unit 242 for storing constraints on the placement of the virtual ECUs and conditions on how the virtual ECUs are to be placed in the first ECU 220 and the second ECU 224 when the in-vehicle system 200 is started up. The storage unit 242 stores such conditions in the form of a configuration file, which is read when the controller 240 is started up. Hereinafter, the configuration will be referred to as a "config" and the configuration file will be referred to as a "config file." Examples of the contents of a configuration file will be described later.

[0046] FIG. 5 shows another example of a controller arrangement. Referring to FIG. 5 , an in-vehicle system 300 includes an in-vehicle network 322, a first ECU 320 and a second ECU 324 that can communicate with each other via the in-vehicle network 322 and can each host one or more virtual ECUs, and a controller ECU 326 that is a controller device that can communicate with the in-vehicle network 322 and the second ECU 324 via the in-vehicle network 322 and is provided independently of the in-vehicle network 322 and the second ECU 324. In this example, the controller ECU 326 includes a memory unit 342 similar to the memory unit 242 shown in FIG. 4 . A controller 340 implemented by a program operates in the controller ECU 326. The controller ECU 326 has the memory unit 342 for storing a configuration file. Unlike the first ECU 320 and the second ECU 324, the controller ECU 326 does not use virtualization technology. The controller ECU 326 operates as an independent ECU, as in the past.

[0047] In this embodiment, the storage units 242 and 342 store three types of configuration files: a destination configuration, a priority configuration, and an initial resource configuration.

[0048] 6, the operation destination designation configuration 370 lists the ECU in which each virtual ECU should operate for all virtual ECUs. For example, in the case of the in-vehicle system 200 of FIG. 4, virtual machine A (actually designated by the identifier of virtual machine A) runs on the first ECU 220 and cannot be migrated to the second ECU 224. Virtual machine B runs on the second ECU 224 and cannot be migrated to the first ECU 220. It is shown that no such ECU is designated for virtual machine C and virtual machine D. Both virtual machine C and virtual machine D can operate on either the first ECU 220 or the second ECU 224, and therefore can be migrated.

[0049] In this example, the information "not specified" for virtual machine C and virtual machine D is written in the operation destination designation configuration 370, but this disclosure is not limited to such a form. For example, it may be arranged that "not specified" is specified as the default for virtual ECUs not listed in the operation destination designation configuration 370. In this case, however, it is necessary to somehow identify all of the virtual ECUs to be started. For example, a separate configuration file listing the identifiers of all virtual ECUs may be provided.

[0050] An ECU can be specified by its name, identifier, or address. A predetermined symbol or number may be assigned to each ECU, and the ECU may be specified by that symbol or number. A vector with elements equal to the number of ECUs may be prepared, and each element may be associated with an ECU. For ECUs that can be operated by the virtual ECU, the value of the corresponding element may be set to, for example, "0," and for ECUs that cannot be operated, the value of the element may be set to, for example, "1," and the ECU may be specified by the vector. Alternatively, the array of vector elements may be regarded as binary numbers, and the value may be used to specify the ECU. In this case, values ​​may be expressed using octal or hexadecimal notation, for example.

[0051] By using the operation destination specification configuration 370 in this way, the ECU on which each virtual machine is to run can be appropriately controlled.

[0052] FIG. 7 shows an example of the contents of the priority configuration 372. Referring to FIG. 7, the priority configuration 372 stores the priority of each virtual ECU. In this embodiment, there are three levels of priority: high, medium, and low. In the case of an in-vehicle system, the functions realized by the virtual ECU include functions with different priorities, such as functions requiring high reliability, functions necessary for the vehicle but not requiring high reliability, and functions that are desirable but not essential for vehicle control. For example, functions such as driving, turning, and stopping are related to the vehicle's essential functions and require high reliability. Among additional functions, functions with relatively high priority, such as power window control and infotainment, are desirable for the vehicle but do not require particularly high reliability. Furthermore, functions with relatively low priority, such as so-called infotainment functions, are not essential functions and are not essential for the vehicle.

[0053] As described above, resources must be allocated preferentially to virtual ECUs that implement functions that require high reliability. On the other hand, functions that are not essential for vehicle control have a low priority for resource allocation. Each virtual ECU corresponds to one of these functions. Therefore, the priority configuration 372 describes the priority for each virtual ECU.

[0054] In this example, there are three levels of priority, but this disclosure is not limited to such an embodiment. There may be cases where two levels of priority are sufficient, or where four or more levels are required.

[0055] 8 shows an example of the contents of the initial resource specification configuration 374. When the in-vehicle system is started, each virtual ECU needs to be started. It is desirable that the placement of the virtual ECUs at the time of start-up be optimized while complying with the above-mentioned constraints. The conditions for this are described in the initial resource specification configuration 374. In other words, when the in-vehicle system is started, the initial allocation of resources to each virtual ECU is performed in accordance with the description of this initial resource specification configuration 374.

[0056] Referring to FIG. 8 , in this example, the initial resource designation configuration 374 describes, for each virtual ECU, the physical resources (such as the number of cores in a CPU (Central Processing Unit) and memory size) to be allocated to each virtual ECU when it is started. As will be described later, the controller determines the optimal placement of the virtual ECUs by referring to the contents of this initial resource designation configuration 374. Note that after the in-vehicle system is started, the placement of the virtual ECUs dynamically changes depending on the resource usage status of each ECU. Therefore, in this embodiment, the initial resource designation configuration 374 shown in FIG. 8 is used only to determine the placement of the virtual ECUs when the in-vehicle system is started. Of course, the initial resource designation configuration 374 can also be used to maintain the initial placement as much as possible while dynamically changing the resource placement.

[0057] In this embodiment, after the in-vehicle system is started, the controller performs two types of processing on the virtual ECU: migration and resource reduction. These will be described below.

[0058] First, migration will be described. Migration refers to transferring a virtual ECU running on one ECU to another ECU within the same ECU cluster. While the operation of the other virtual ECUs within the ECU cluster is not stopped, the virtual ECU being migrated is stopped for a moment (several milliseconds). Therefore, migration should not be performed on virtual ECUs that require high reliability. Furthermore, virtual ECUs that have a designated ECU for operation cannot be migrated. Therefore, in this embodiment, the following restrictions are imposed. By imposing the following restrictions, virtual ECUs that are less important and independent of devices can be actively migrated. As a result, the load on each ECU can be distributed, enabling stable operation of the virtual ECUs on each ECU.

[0059] High priority virtual ECU: Migration not possible Medium priority virtual ECU: Migration possible Low priority virtual ECU: Migration possible Virtual ECU with designated operating destination: Migration not possible Virtual ECU without designated operating destination: Migration possible

[0060] Referring to FIG. 9 , it is assumed that the in-vehicle ECU cluster 400 includes a first ECU 410 and a second ECU 412. A virtual machine A is running in the first ECU 410. Its resource occupancy rate is 30%. No other virtual ECUs are running in the first ECU 410. Therefore, the available resources are 70%. Note that the "resource occupancy rate" is a concept that combines the CPU occupancy rate and the memory occupancy rate. How the resource occupancy rate is calculated varies depending on the designer's ideas.

[0061] Meanwhile, virtual machine B and virtual machine C are running on virtual machine B 420, with their resource occupancy rates of 40% and 55%, respectively. The available resources are 5%. The controller is programmed to determine that the ECU's resources are constrained when the amount of available ECU resources falls below a predetermined threshold (e.g., 15%). In this case, in the state shown in FIG. 9 , the second ECU 412 is determined to be constrained.

[0062] In the example shown in Figure 9, it is assumed that migration is permitted for both virtual machine B and virtual machine C. In this case, the controller determines the virtual ECU to migrate so that the allocation of resources after the migration is as equal as possible. That is, in the example shown in Figure 9, virtual machine B 420 is migrated 422 from the second ECU 412 to the first ECU 410. As a result, the available resources of the first ECU 410 decrease by 30%, but this does not result in a resource shortage. In the second ECU 412, the available resources increase to 45%, allowing virtual machine C to maintain stable operation.

[0063] If the migration 422 shown in FIG. 9 alone cannot avoid a situation in which the resources of the first ECU 410 or the second ECU 412 become constrained, the controller executes a process of reducing the resource allocation to the virtual ECU (resource reduction process).

[0064] The resource reduction process will be described below. Note that the resource reduction process affects the performance of the target virtual ECU. Therefore, the following restrictions are set for the allocation and reduction of resources.

[0065] High priority virtual ECU: Can use resources without restrictions. Not subject to resource reduction. Medium priority virtual ECU: Can use resources without restrictions. Not subject to resource reduction. Low priority virtual ECU: Can use resources as long as they are available. However, they are subject to resource reduction when resources are tight.

[0066] FIG. 10 shows an overview of the resource allocation process. Referring to the left side of FIG. 10 , for example, assume that in ECU 430, the resource occupancy rate of high-priority virtual machine A has risen to 60%, resulting in free resources 440 falling below a threshold of 5%, indicating resource congestion. Virtual machine A may request additional resources. At this time, there may be cases where other ECUs do not have sufficient free resources, making it impossible to migrate low-priority virtual machine B to another ECU. In such cases, in this embodiment, as shown on the right side of FIG. 10 , an attempt is made to alleviate the resource congestion by reducing the resources allocated to low-priority virtual machine B, thereby increasing the amount of free resources 442 to a threshold value or higher (e.g., 20%).

[0067] Techniques for reducing allocated resources include reducing the number of allocated cores in the case of a CPU, and techniques such as memory ballooning, memory swapping, and memory compression in the case of memory.

[0068] C. Hardware and Software Figure 11 is a block diagram showing the hardware configuration for realizing an in-vehicle system 450 according to this embodiment. Referring to Figure 11, the in-vehicle system 450 includes an in-vehicle network 462 and a first ECU cluster 452, a second ECU cluster 454, and a third ECU cluster 456, all of which are connected to the in-vehicle network 462. While these clusters may differ in specific configuration (such as the number of ECUs and the number of virtual machines running), they share a common basic configuration. Therefore, the following description will focus on the configuration and operation of the first ECU cluster 452.

[0069] The first ECU cluster 452 includes an ECU 460 connected to an in-vehicle network 462 and one or more ECUs 466 connected to the in-vehicle network 462. In this embodiment, the ECU 460 and each of the multiple ECUs 466 are of the same standard. The ECU 460 can also be used as an ECU that provides a virtualization infrastructure, or as a controller ECU. In the following description, the ECU 460 is referred to as the controller ECU, and virtual ECUs are assumed to operate in the multiple ECUs 466.

[0070] The ECU 460 is essentially a computer and includes a CPU 482, a main memory device 484, an auxiliary memory device 486, an input / output I / F (Interface) 488, an in-vehicle network communication unit 490, and a bus 480 that communicatively connects all of these components to one another. Signals from various devices 464, such as a camera, and CAN (Controller Area Network) signals are input to the input / output I / F 488. The in-vehicle network communication unit 490 is an I / F for the ECU 460 to an in-vehicle network 462. The ECU 460 can communicate with all of the other ECUs belonging to the plurality of ECUs 466 via the in-vehicle network communication unit 490 and the in-vehicle network 462.

[0071] The program executed by the CPU 482 is stored in the auxiliary storage device 486. When the CPU 482 executes a program, it reads the program from a specified address in the auxiliary storage device 486. The CPU 482 loads the program into the main storage device 484, reads instructions from the specified address, and executes them. The CPU 482 decodes the read instructions. As a result of the decoding, the CPU 482 reads data from the address specified by the instruction, performs the operation specified by the decoded result, and stores the result at the address specified by the instruction. The CPU 482 has a program counter (not shown), and updates its contents according to the result of executing the instruction. The CPU 482 reads and executes a new instruction from the address in the main storage device 484 specified by the updated program counter. By executing these processes, the CPU 482 realizes the function defined by the program.

[0072] In this embodiment, it is assumed that the CPU 482 has multiple cores and is capable of executing speculative instructions, thereby enabling various processes to be executed at high speed.

[0073] The virtual ECU is actually a file installed in the auxiliary storage device 486. A virtualization program, also installed in the auxiliary storage device 486, is loaded into the main storage device 484 and executed by the CPU 482. The virtualization program reads the virtual ECU file and emulates the CPU according to the contents of the file, thereby realizing the virtual ECU. Specifically, it is desirable to use a type of virtualization program called a hypervisor, which provides direct access to the computer's hardware resources without going through the host OS. Of course, the virtualization program is not limited to a hypervisor, and a virtualization program that runs on the host OS may also be used.

[0074] The control structure of a program that realizes the functions of the controller in this embodiment will be described below. Here, the controller is assumed to be an application that runs on the host CPU, not in a virtualized environment, in a dedicated computer, the controller ECU 326, as shown in FIG. 5 . This program is activated when the controller ECU 326 is started and the controller program (hereinafter referred to as the "controller program") is loaded into memory during the startup sequence. This program repeatedly executes the process described below, detecting and executing any processing requests related to maintaining the virtual machine (such as migration and resource reduction requests) in real time. "Real-time execution" here refers to so-called real-time processing in information processing technology. Real-time processing is a concept contrasted with batch processing, and refers to processing any processing request immediately upon occurrence.

[0075] 12, immediately after startup, the controller program allocates and initializes a storage area, initializes various control variables, and then includes step 500 of reading the virtual ECU's operation destination designation configuration 370 (FIG. 6), step 502 of reading the virtual ECU's priority designation configuration 372 (FIG. 7), and step 504 of reading the virtual ECU's initial resource designation configuration 374 (FIG. 8). The controller program stores the information read from these configuration files in various variables within the program.

[0076] This program further includes step 506 of activating all the virtual ECUs after step 504. To activate all the virtual ECUs, the information read in steps 500, 502 and 504 is required.

[0077] This program further includes step 508 of optimizing the resources allocated to each virtual ECU after step 506. Step 508 is repeatedly executed while the in-vehicle system is operating.

[0078] This program further includes step 510, in which after the in-vehicle system is instructed to stop and the processing of step 508 is completed, all virtual ECUs are terminated and the execution of the controller program is terminated.

[0079] Referring to Figure 13, step 506 of starting the virtual ECU includes step 530 of extracting all virtual ECU placement patterns specified by the operation destination specification configuration 370, and step 532 of narrowing down the placement patterns extracted in step 530 to the placement pattern that minimizes the number of high-priority machines placed in each standalone ECU.

[0080] This program further includes step 534, which calculates the resource usage rate of each ECU for each of the placement patterns remaining in step 532 based on the contents of the initial resource specification configuration 374. As mentioned above, the resource usage rate here is a concept that combines the CPU usage rate and the memory utilization rate. This program also includes step 536, which branches the control flow depending on whether there is a placement pattern in which both the CPU usage rate and the memory usage rate calculated in step 534 are equal to or less than a specified value. The specified value here refers to both a first specified value, which is a specified value for the memory usage rate, and a second specified value, which is a specified value for the memory usage rate. These two types of specified values ​​do not need to be the same. Note that, although multiple types of specified values ​​appear in the following description, these values ​​may be the same or different.

[0081] This program further includes step 538, when the determination in step 536 is negative, branching the control flow depending on whether or not there is an arrangement pattern that results in a CPU utilization rate that is equal to or less than a third specified value, and step 540, when the determination in step 538 is negative, branching the control flow depending on whether or not there is an arrangement pattern that results in a memory utilization rate that is equal to or less than a fourth specified value. In this embodiment, the third specified value is the same as the first specified value in step 536. However, the two do not necessarily have to be the same. For example, the third specified value may be equal to or less than the first specified value. Similarly, in this embodiment, the fourth specified value is the same as the second specified value, but they do not have to be the same. For example, the fourth specified value may be equal to or less than the second specified value.

[0082] This program includes step 542, when the determination in step 536, 538, or 540 is affirmative, narrowing down the placement patterns to those that meet the conditions specified in these steps, and step 544, selecting the placement pattern that minimizes the difference in CPU utilization rate among all ECUs from the placement patterns remaining in step 542. This program further includes step 546, in which virtual ECUs are allocated to each ECU in accordance with the placement pattern selected in step 544, all virtual ECUs are started, and step 506 is terminated.

[0083] If the determination in step 540 is negative, processing for when an appropriate placement for the virtual ECU is not found is executed in step 548. In step 548, for example, it is conceivable to change the configuration file so that low-priority virtual ECUs are not started, and then execute step 506 again. Alternatively, it is possible to uniformly reduce the resources allocated to low-priority virtual ECUs, and then execute step 506 again. In some cases, it may be possible to display a message that the virtual ECU cannot be started, and receive instructions from the user.

[0084] In addition, the "difference" in the "arrangement pattern with the smallest difference in CPU utilization rate" in step 544 may be any of the range (difference between the maximum and minimum values), average deviation, or variance of the CPU utilization rate in each of the arrangement patterns after calculating the CPU utilization rate in each arrangement pattern for all ECUs.

[0085] 14, step 508 in FIG. 12 includes step 600 of monitoring the resource usage rate of each ECU, and step 602 of branching the control flow depending on whether or not there is an ECU with tight resources as a result of the monitoring in step 600. The determination in step 602 is affirmative, for example, when the CPU usage rate or memory usage rate of a certain ECU exceeds a specified value. If the determination in step 602 is negative, control returns to step 600, and resource monitoring is performed again.

[0086] This program further includes step 604, in which, when the determination in step 602 is affirmative, one of the virtual ECUs operating in the ECU determined to be under resource pressure is migrated to another ECU. The details of the processing in step 604 will be described later with reference to FIG. 15 .

[0087] This program further includes, after step 604, step 606, which branches the control flow depending on whether the resource constraint has been resolved. The determination in step 606 is made based on whether the resource usage rates of all ECUs in the in-vehicle system are equal to or less than a specified value. If the determination in step 606 is affirmative, control returns to step 600, where resource monitoring is resumed. This program further includes step 608, which is executed in response to a negative determination in step 606, and reduces the resources of the low-priority machine. Thereafter, control returns to step 600. The content of step 608 will be described later with reference to FIG. 16 . As described above, in this embodiment, the controller constantly monitors whether resource constraint has occurred by comparing various indicators with specified values. If the result of comparing the indicators with the specified values ​​indicates that resource constraint has occurred, the controller determines that it is necessary to resolve the constraint and immediately executes processing to do so.

[0088] The control structure of the program that executes the migration in step 604 will be described with reference to Fig. 15. Step 604 includes step 650, which branches the control flow depending on whether there is a medium- or low-priority virtual ECU running in the resource-constrained ECU. If the determination in step 650 is negative, execution of step 604 ends.

[0089] Step 604 further includes step 652 of extracting a virtual ECU that can be migrated when the determination in step 650 is positive, and step 654 of extracting all feasible migration patterns for the virtual ECU extracted in step 652 and calculating a predicted resource utilization rate after migration for each pattern.

[0090] Step 604 further includes step 656, which branches the control flow depending on whether or not a combination exists in which both the CPU utilization rate and the memory utilization rate are equal to or less than a specified value as a result of the processing in step 654, and step 658, which, when the determination in step 656 is affirmative, executes migration of the target virtual ECU so as to realize the combination found in step 656, and ends step 604. Note that the specified value of the CPU utilization rate in step 656 is a fifth specified value, and the specified value of the memory utilization rate is a sixth specified value.

[0091] Step 604 further includes step 660, which branches the control flow according to whether or not there is a combination that results in a CPU usage rate that is equal to or lower than the seventh specified value when the determination in step 656 is negative, and step 662, which performs migration of the target virtual ECU so as to realize the combination found in step 660, and terminates step 604 when the determination in step 660 is positive.

[0092] Step 604 further includes step 664, in which, when the determination in step 660 is negative, the flow of control branches according to whether or not there is a combination in which the memory usage rate is equal to or less than the eighth specified value, and step 666, in which, when the determination in step 664 is positive, migration of the target virtual ECU is performed to realize the combination found in step 664, and step 604 is terminated. If the determination in step 664 is negative, step 604 is terminated without performing migration.

[0093] In steps 658 and 662 or step 664, if there are multiple possible combinations, a combination may be selected using criteria similar to those in step 544 of FIG.

[0094] 16, step 608 in Fig. 14 includes step 700 of extracting all low-priority machines operating in the ECU (target ECU) in which resource pressure has been detected, step 702 of branching the control flow depending on whether the CPU utilization rate of the target ECU is equal to or greater than a ninth specified value, and step 704 of uniformly reducing the CPU utilization rate of all low-priority machines operating in the target ECU by a fixed amount when the determination in step 702 is negative. When the determination in step 702 is negative, control proceeds to step 706.

[0095] Step 608 further includes, after step 704, step 706 for branching the control flow depending on whether the memory usage rate in the target ECU is equal to or greater than a tenth specified value, and step 708 for, if the determination in step 706 is affirmative, reducing the memory usage of all low-priority machines in the target ECU by a fixed percentage (or a fixed amount) and terminating execution of step 608. If the determination in step 706 is negative, execution of step 608 terminates.

[0096] 2. Operation The first ECU cluster 452 (FIG. 11) having the above-described configuration operates as follows.

[0097] 11, when the power supply of the in-vehicle system 450 is turned on, the ECU 460 and the plurality of ECUs 466 of the first ECU cluster 452 are started up. In each of the plurality of ECUs 466, the hypervisor is started up and the ECUs are put into a state of waiting for an instruction to start a virtual ECU.

[0098] The ECU 460 operating as the controller ECU operates as follows: It is assumed that the operation destination designation configuration 370, the priority designation configuration 372, and the initial resource designation configuration 374 are all stored in the auxiliary storage device 486.

[0099] Referring to FIG. 12, ECU 460 reads out operation destination specification configuration 370, priority specification configuration 372 and initial resource specification configuration 374 from auxiliary storage device 486 (steps 500, 502 and 504), and substitutes each specified value into predetermined variables of the program.

[0100] 13 , ECU 460 executes steps 530, 532, and 534 to calculate resource usage rates for each possible virtual ECU placement pattern. Furthermore, if a virtual ECU placement pattern that satisfies the conditions is found in step 536, 538, or 540, ECU 460 narrows down the virtual ECU placement patterns to that placement pattern in step 542. Furthermore, in step 544, ECU 460 calculates the CPU usage rate of each ECU for the virtual ECUs in first ECU cluster 452 for each of the remaining placement patterns. Furthermore, ECU 460 selects, for each placement pattern, the placement pattern that minimizes the difference in CPU usage rates among the ECUs. In step 546, ECU 460 allocates and activates each virtual ECU to its corresponding ECU according to the selected placement pattern, and then ends the processing of step 506.

[0101] B. Monitoring and Resource Adjustment Returning to Fig. 12, ECU 460 starts the resource optimization process in step 508. Referring to Fig. 14, ECU 460 monitors the resources in each ECU. Specifically, ECU 460 calculates the CPU usage rate and memory usage rate in each ECU.

[0102] In step 602, ECU 460 determines whether or not there is an ECU that is running low on resources. If there is no such ECU, control returns to step 600, and ECU 460 resumes resource monitoring. If there is an ECU that is running low on resources, ECU 460 performs the migration process shown in FIG. 15 in step 604.

[0103] 15 , in the migration process of step 604, the ECU 460 selects a low-priority machine that is available for migration and is running in the ECU (target ECU) for which resource constraints were detected in step 602 of FIG. 14 . Furthermore, in step 654, the ECU 460 extracts all feasible migration patterns for the medium- and low-priority machines extracted in step 652. Also in step 654, the ECU 460 calculates the post-migration resource usage rate for each of the extracted migration patterns. Based on this resource usage rate prediction, feasible migrations are executed in steps 656, 658, 660, 662, 664, and 666. If the resource constraints are not resolved by the resource usage rate prediction even after migration, the determinations in steps 656, 660, and 664 are all negative, and migration is not executed.

[0104] 14, if the resource shortage is resolved as a result of executing step 604, the determination in step 606 becomes positive and the resource optimization process ends. If the resource shortage is not resolved, step 608 is executed.

[0105] 16, in step 608, if the CPU usage rate of the ECU in which resource pressure is detected is equal to or greater than a ninth specified value (the determination in step 702 is affirmative), the CPU usage of all low-priority machines running on that ECU is uniformly reduced (step 704). Furthermore, if the memory usage of that ECU is equal to or greater than a tenth specified value (the determination in step 706 is affirmative), the memory usage of all low-priority machines running on that ECU is reduced.

[0106] If the determination in step 702 is negative, no resource reduction processing is performed in step 608. If the determination in step 702 is positive and the determination in step 706 is negative, the CPU usage of the low-priority machine is reduced, but the memory usage is not reduced.

[0107] As described above, according to this embodiment, an ECU cluster is formed using multiple ECUs, and a controller manages the virtual ECUs executed in each ECU. In this management, when a resource shortage occurs in an ECU, the controller migrates the virtual ECU from that ECU to another ECU to relieve the resource shortage in that ECU. If the resource shortage is not relieved even after the migration, the controller reduces the resources of the low-priority virtual ECU running in that ECU. This allows other higher-priority machines running in that ECU to use those resources. By performing this management by the controller, the load of the ECUs is dynamically redistributed, thereby maintaining the functionality of the in-vehicle system.

[0108] Second Modification: In the above embodiment, it is assumed that the in-vehicle system has one ECU cluster. However, this disclosure is not limited to such an embodiment. The in-vehicle system may have multiple ECU clusters. In this case, each ECU cluster has its own controller, and each ECU cluster independently performs dynamic load redistribution. As a result, even if the overall size of the in-vehicle system increases and the number of ECUs increases, dynamic load redistribution can be easily performed.

[0109] In the above embodiment, the information about the virtual ECUs in each ECU is synchronized between the ECUs. However, this disclosure is not limited to such an embodiment. Such synchronization may be performed immediately before migration, rather than constantly.

[0110] In the above embodiment, the layout configuration information for the virtual ECUs is described in three configuration files. However, this disclosure is not limited to such an embodiment. The layout configuration information may be described in one configuration file, or in two or more configuration files. Furthermore, the layout configuration information for the virtual ECUs does not need to be written in a file. The layout configuration information may be stored in, for example, a database. This database may be provided for each ECU cluster, or only one for the entire in-vehicle system. If only one database is provided for the entire in-vehicle system, an identifier must be assigned to each ECU cluster, and each record in the database must have a field for that identifier. Furthermore, the layout configuration information for these virtual ECUs may be written collectively as literals within the source program of the controller program. In this case, the controller program must be compiled, but the content of the layout configuration information itself can be easily changed. Furthermore, for example, a program may be created separately from the controller program that, when called, returns the layout configuration information for that ECU cluster or a pointer indicating its storage address in a specific format as a return value. In this case, recompiling the controller program itself is not necessary.

[0111] In the above embodiment, the configuration file describes the layout configuration information for each specific virtual ECU name or identifier. However, this disclosure is not limited to such an embodiment. For example, a predetermined class may be defined in advance for the virtual machine priority, the initially allocated resources, or a combination thereof. In this case, the priority, the initially allocated resources, or a combination thereof may be specified by the class name or class identifier.

[0112] The embodiments disclosed herein should be considered to be illustrative in all respects and not restrictive. The scope of the present disclosure is not defined by the detailed description of the disclosure, but by the claims of the appended claims, and is intended to include all modifications within the meaning and scope of the claims.

[0113] 42, 100, 430, 460 ECU 60, 170, 172 Physical hardware layer 62 Virtualization infrastructure layer 64 Virtual machine layer 110, 150, 220, 320, 410 First ECU 112, 152, 224, 324, 412 Second ECU 140, 400 In-vehicle ECU cluster 154 Synchronization processing unit 176, 422 Migration 200, 300, 450 In-vehicle system 222, 322, 462 In-vehicle network 230 Sensor 232 Vehicle body control signal line 240, 340 Controller 242, 342 Storage unit 326 Controller ECU 370 Operation destination specification configuration 372 Priority configuration 374 Initial resource specification configuration 420 Virtual machine B 440, 442 Free resources 452 First ECU cluster 454 Second ECU cluster 456 Third ECU cluster 464 Various devices 466 Multiple ECUs 480 Bus 482 CPU 484 Main storage device 486 Auxiliary storage device 488 Input / output I / F 490 In-vehicle network communication unit

Claims

1. An in-vehicle system including an information processing device cluster including a first information processing device and a second information processing device capable of communicating with each other, Each of the first information processing device and the second information processing device Computer hardware, and A virtualization platform that operates on the computer hardware, The in-vehicle system further includes a controller for operating one or more virtual machines on the virtualization platform of the first information processing device and the second information processing device, the controller monitors the usage of hardware resources in the first information processing device and the second information processing device, and changes the configuration of the one or more virtual machines in real time depending on the usage of the hardware resources.

2. The in-vehicle system according to claim 1 , wherein the controller includes a controller device capable of communicating with the first information processing device and the second information processing device included in the information processing device cluster, and provided independently of the first information processing device and the second information processing device.

3. The in-vehicle system according to claim 1 , wherein the controller includes a virtual controller executed on the virtualization platform of the first information processing device.

4. The controller: a placement configuration recording unit configured to record placement configuration information that defines a placement configuration of the one or more virtual machines; 4. The in-vehicle system according to claim 1, further comprising: a placement control unit that monitors the operating status of the first information processing device and the second information processing device, and determines in real time the placement of the one or more virtual machines within the information processing device cluster so that the one or more virtual machines operate stably, and changes the placement if necessary.

5. The arrangement configuration information is operation destination designation information recording a virtual machine to be operated in an information processing device that is a specific operation destination for the one or more virtual machines, and information designating the information processing device that is the specific operation destination; Priority information that specifies a priority for allocating the hardware resources to the one or more virtual machines; initial resource information specifying an initial allocation of the hardware resources upon boot-up of the one or more virtual machines; or The in-vehicle system according to claim 4 , further comprising at least two of the operation destination designation information, the priority information, and the initial resource information.

6. The arrangement configuration information is operation destination designation information recording a virtual machine to be operated in a specific information processing device as an operation destination for the one or more virtual machines, and information designating the specific information processing device as the operation destination; priority information that specifies a priority when allocating the hardware resources to the one or more virtual machines; the priorities include a first priority which is the highest and a second priority which is lower than the first priority, 5. The in-vehicle system of claim 4, wherein the placement control unit monitors the usage status of the hardware resources in the first information processing device, and in response to detection of a shortage of the hardware resources in the first information processing device, includes a working destination control unit that selects, from among the virtual machines running on the first information processing device, a virtual machine that is indicated by the working destination designation information as being capable of being moved to the second information processing device and has the second priority, and moves it to the second information processing device.

7. 7. The in-vehicle system of claim 6, wherein the placement control unit further includes a resource reduction unit that monitors the usage status of the hardware resources in the first information processing device and the second information processing device, and in response to detection of a hardware resource shortage in the in-vehicle system even after a virtual machine is moved by the operation destination control unit, reduces the allocation of the hardware resources to a virtual machine having the second priority among the virtual machines running on the information processing device where the hardware resource shortage has been detected.

8. The in-vehicle system according to claim 1 , comprising a plurality of the information processing device clusters.

9. A method for controlling an in-vehicle system including an information processing device cluster including a first information processing device and a second information processing device capable of communicating with each other, comprising: Each of the first information processing device and the second information processing device Computer hardware, and A virtualization platform that operates on the computer hardware, The control method includes: A computer operates one or a plurality of virtual machines on the virtualization infrastructure of each of the first information processing device and the second information processing device; A computer monitors usage status of hardware resources in the first information processing device and the second information processing device; and changing a configuration of the one or more virtual machines in real time in response to detection of a hardware resource shortage in the first information processing device.