In-vehicle system and method for controlling the 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

Technical Field

[0001] This disclosure relates to an in-vehicle system and a method for controlling an in-vehicle system. This application claims priority based on Japanese Application No. 2022-138903 filed on September 1, 2023, and incorporates herein by reference all the descriptions set forth in the Japanese application.

Background Art

[0002] Conventionally, a plurality of ECUs (Electronic Control Units), which are control devices for controlling each part of a vehicle, are provided in a vehicle. An ECU is essentially a computer. Therefore, an ECU can perform interrupt processing and can appropriately respond even in an emergency.

[0003] An ECU was originally used for engine control. However, as vehicle equipment becomes more electronic, ECUs are being used in various locations. For example, an ECU is also responsible for processing information collected by providing various sensors in a vehicle. An ECU is also used for determining the driving state of a vehicle, controlling brakes, controlling electrical equipment, and further for a lane keeping system, an inter-vehicle distance control system, etc.

[0004] On the other hand, the processing performed by an ECU in a vehicle is also increasing more than the increase in the number of ECUs mounted in the vehicle. Therefore, there is a technique of dividing these processes into a plurality of tasks and executing them in a plurality of ECUs respectively. 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 disperse the load of the ECUs.

[0005] One solution to these problems is disclosed in Patent Document 1. The technology disclosed in Patent Document 1 involves providing the ECU executing the task with a virtual device driver that allows the transparent use of external devices. When the task is transferred (migrated) to another ECU, this virtual device driver is also transferred to the destination ECU. In this way, the external device can be made transparently available to the destination ECU as well. This migration is performed while the ECU is running. Such migration is called "live migration". All migrations described in this specification are live migrations, and for the purpose of brevity, they are simply referred to as "migration". [Prior art documents] [Patent Documents]

[0006] [Patent Document 1] Japanese Patent Publication No. 2009-070135 [Patent Document 2] Japanese Patent Publication No. 2013-003946 [Patent Document 3] International Publication No. 2021 / 010124 [Overview of the project]

[0007] The in-vehicle system relating to the first aspect of this disclosure is an in-vehicle system including an information processing cluster including a first information processing device and a second information processing device that can communicate with each other, wherein each of the first and second information processing devices 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 and second information processing devices, the controller monitors the usage of computer hardware resources in the first and second information processing devices and changes the configuration of one or more virtual machines in real time according to the usage of hardware resources.

[0008] The above and other purposes, features, aspects and advantages of this disclosure will become apparent from the following detailed description of this disclosure, which will be understood in conjunction with the attached drawings. [Brief explanation of the drawing]

[0009] [Figure 1] Figure 1 is a block diagram illustrating the schematic configuration of an ECU using virtualization technology. [Figure 2] Figure 2 is a schematic diagram illustrating the ECU cluster. [Figure 3] Figure 3 is a schematic diagram illustrating the migration of virtual ECUs in an ECU cluster. [Figure 4] Figure 4 is a block diagram showing an example of the arrangement of controllers that control the ECU cluster. [Figure 5] Figure 5 is a block diagram showing another example of the controller configuration for controlling the ECU cluster. [Figure 6] Figure 6 is a schematic diagram showing an example of the contents of a configuration file for specifying the operating location, used in the embodiment. [Figure 7] Figure 7 is a schematic diagram showing an example of the contents of a priority configuration file used in the embodiment. [Figure 8] Figure 8 is a schematic diagram showing an example of the contents of a configuration file for initial resource specification used in the embodiment. [Figure 9] Figure 9 is a schematic diagram illustrating the migration of virtual machines between different ECUs. [Figure 10] Figure 10 is a schematic diagram illustrating the reduction in resource usage (increase in available resources) within a single ECU. [Figure 11] Figure 11 is a block diagram showing the hardware configuration of the in-vehicle system and ECU related to this disclosure. [Figure 12]Figure 12 is a flowchart showing the control structure of a resource management program executed by the controller of the in-vehicle system in the embodiment. [Figure 13] Figure 13 is a flowchart showing the control structure of a computer program that implements the process for starting the virtual machine shown in Figure 12. [Figure 14] Figure 14 is a flowchart showing the control structure of a computer program that implements the resource optimization process shown in Figure 12. [Figure 15] Figure 15 is a flowchart showing the control structure of the computer program that implements the migration shown in Figure 14. [Figure 16] Figure 16 is a flowchart showing the control structure of a computer program that implements the resource reduction process shown in Figure 14. [Modes for carrying out the invention]

[0010] [Issues this disclosure aims to address] With recent advancements in computer technology, it has become possible to build a virtualization infrastructure on a single ECU and run multiple virtual machines, each using an independent OS (Operating System) and BSW (Basic Software), on this virtualization infrastructure. In other words, one or more virtual ECUs can run on a single ECU. As a result, the numerous ECUs used in a vehicle can be consolidated into a relatively small number of ECUs. However, even when running multiple virtual machines on such a relatively small number of ECUs, it is necessary to dynamically distribute the load on each ECU.

[0011] The technology disclosed in the above Patent Document 1 is load distribution at the task level of an application. When the technology disclosed in Patent Document 1 is applied to an ECU in which a virtual machine is operating, it means load distribution among a plurality of virtual ECUs operating on that ECU. By such a method, the load on the ECU itself in which the virtual machine is operating cannot be reduced. Such problems can occur similarly not only in ECUs but also in information processing devices mounted on a vehicle in multiple numbers.

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

[0013] [Effects of this disclosure] According to this disclosure as described above, an in-vehicle system and a control method that can dynamically control the load of an information processing device in which a virtual machine is operating can be provided.

[0014] [Description of embodiments of this disclosure] Summarizing this disclosure is 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 capable of communicating with each other. Each of the first information processing device and the second information processing device includes computer hardware and a virtualization infrastructure operating on the computer hardware. The in-vehicle system further includes a controller for operating one or more virtual machines in the virtualization infrastructures of the first information processing device and the second information processing device. 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 one or more virtual machines in real time according to the usage status of the hardware resources.

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

[0017] (2) In (1) above, the controller may include a controller device that is included in the information processing device cluster, is capable of communicating with the first information processing device and the second information processing device, and 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 and second information processing devices, and functions as a controller. As a result, the controller device is not affected by the dynamic control of the load of the information processing devices, and the dynamic control of the load of the information processing devices for the execution of virtual machines in the in-vehicle system can be performed stably.

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

[0020] The controller is implemented as a virtual controller on the virtualization platform of the first information processing unit. This eliminates the need for separate hardware to run the controller, keeping the cost of the in-vehicle device low and simplifying 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 defining the placement configuration of one or more virtual machines, and a placement control unit that monitors the operating status of the first information processing unit and the second information processing unit, and determines in real time the placement of one or more virtual machines within the information processing unit cluster so that 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 virtual machines, only the contents of the placement configuration unit need to be changed; there is no need to change the functions of the placement control unit. As a result, changes to the virtual machine placement configuration can be easily made.

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

[0024] When using destination specification information, for example, it is possible to prevent a virtual machine that needs to run on a specific information processing device from being moved to another information processing device. When using 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 provide the required functions stably. When using initial resource information, the placement of virtual machines can be quickly determined when the in-vehicle system starts up. There is no need to adjust the placement of virtual machines after startup, 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 specification information which records, for one or more virtual machines, a virtual machine to be run in an information processing device that is a specific destination, and information which specifies the information processing device that is a specific destination, and priority information which specifies the priority when allocating hardware resources for one or more virtual machines, and the priority may include the highest first priority and a second priority which is lower than the first priority, and the deployment control unit may monitor the usage of hardware resources in the first information processing device, and in response to the detection of hardware resource shortage in the first information processing device, it may include a destination control unit which selects a virtual machine among the virtual machines running in the first information processing device that is indicated by the destination specification information as being moveable to the second information processing device and has a priority of second priority, and moves it to the second information processing device.

[0026] When hardware resource constraints are detected in the first information processing unit, virtual machines that are moved from the first information processing unit to the second information processing unit are those that are available for movement to the second information processing unit and have been assigned the second priority. This eliminates the possibility that virtual machines crucial for realizing the functions of the in-vehicle system may be moved to an information processing unit that cannot fully perform those functions, allowing the in-vehicle system to stably perform the functions required of it.

[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 unit and the second information processing unit, and in response to the detection of hardware resource congestion in the in-vehicle system even after the virtual machine movement process by the destination control unit, reduces the allocation of hardware resources to virtual machines with a priority of second priority among the virtual machines running in the information processing unit where hardware resource congestion was detected.

[0028] Even after moving virtual machines, hardware resource congestion may still be detected, or the hardware resource congestion may not be resolved because virtual machines cannot be moved. In such cases, the information processing unit that detected the hardware resource congestion reduces the allocation of hardware resources to lower-priority virtual machines. As a result, the amount of hardware resources available to higher-priority virtual machines increases, and the performance of the in-vehicle system can be maintained.

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

[0030] Even when multiple information processing unit clusters are configured, the dynamic distribution of the information processing unit load for virtual machine execution in each cluster can be performed independently. As a result, even if the total number of virtual machines and information processing units used in the in-vehicle system increases, the functionality of the in-vehicle system can be maintained stably.

[0031] (9) A control method for an in-vehicle system relating to the second aspect of this disclosure is a control method for an in-vehicle system including an information processing cluster including a first information processing device and a second information processing device that are able to 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: the 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; the computer monitoring the usage of hardware resources in the first information processing device and the second information processing device; and the first information processing device changing the configuration of one or more virtual machines in real time in response to the detection of hardware resource congestion.

[0032] A single information processing unit cluster comprises a first information processing unit and a second information processing unit, each run by a computer. The computer monitors the hardware resource usage of the first and second information processing units and changes the configuration of the virtual machines in real time according to the hardware resource usage. As a result, the load on the information processing unit on which the virtual machines are running can be dynamically controlled. This load control can be performed independently of the load control in other information processing unit clusters, making it easy to dynamically control the load of virtual machines in an in-vehicle system.

[0033] [Details of the embodiments of this disclosure] Specific examples of in-vehicle systems and their control methods according to embodiments of this disclosure will be described below with reference to the drawings. In the following description and drawings, the same parts are given the same reference numerals. Therefore, detailed descriptions of them will not be repeated. This disclosure is not limited to these examples, but is indicated by the claims, and all modifications within the meaning and scope of the claims are intended to be included. Furthermore, any combination of one or more features of the following embodiments may be used.

[0034] First Embodiment 1. Structure A. ECU Figure 1 shows a schematic configuration of an ECU 42 according to the first embodiment of this disclosure. Referring to Figure 1, the ECU 42 includes a physical hardware layer 60 including computer hardware, a virtualization infrastructure layer 62 built on the physical hardware layer 60, and a virtual machine layer 64 including one or more virtual machines (virtual ECUs) operating in the virtualization infrastructure layer 62. The virtualization infrastructure layer 62 uses hardware resources called the physical hardware layer 60.

[0035] Each virtual ECU performs the same tasks as the conventional ECUs. These virtual ECUs all operate 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 ECUs are the same as those executed by the conventional individual ECUs.

[0036] B.ECU cluster As shown in Figure 1, a single ECU can operate multiple virtual ECUs. However, when multiple virtual ECUs are operated on an individual ECU, the load on a particular ECU may become excessive. It is necessary to avoid such situations.

[0037] To avoid such problems, this embodiment introduces the concept of an ECU cluster. An ECU cluster is a group of multiple ECUs, each running one or more virtual ECUs. As will be described later, an ECU cluster defines the range of destinations when migrating (moving) virtual ECUs. That is, a virtual ECU running in an ECU within a certain ECU cluster can be migrated to another ECU within the same ECU cluster, but not to an ECU in another ECU cluster. Within an ECU cluster constructed in this way, a controller is provided to monitor the resource usage of each ECU within the cluster, thereby leveling the load on each ECU in the cluster or 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 kept relatively small, making management easier and enabling the rapid execution of necessary processing.

[0038] Alternatively, instead of using an ECU cluster, it is possible to avoid situations where the load becomes excessive by making individual ECUs large-scale and high-performance. An example of this approach is shown in the upper part of Figure 2 as ECU100. In this example, a large number of virtual machines are run on ECU100. On the other hand, an example of the ECU cluster approach is shown in the lower part of Figure 2. In the configuration shown in the lower part of Figure 2, an ECU cluster is formed by multiple ECUs (for example, the first ECU110 and the second ECU112) that are smaller in scale and have lower performance than ECU100 shown in the upper part. Multiple virtual ECUs are run on the first ECU110 and the second ECU112, respectively. The performance of these ECUs is inferior to that of ECU100, but by adopting an ECU cluster as shown in the lower part of Figure 2, it is possible to provide the same level of computing resources as in the upper part of Figure 2.

[0039] However, it is preferable to adopt the configuration shown in the lower part of Figure 2 for actual vehicles. The reasons are as follows: As mentioned above, with the configuration shown in the upper part of Figure 1, when the resources of ECU 100 become strained, it is not possible to migrate the virtual ECU to another ECU. In contrast, with the configuration shown in the lower part of Figure 2, it is possible to migrate the virtual ECU between ECUs belonging to the same ECU cluster. Furthermore, when using products of the same standard as the first ECU 110 and the second ECU 112, the number of ECUs can be adjusted according to the performance requirements of the vehicle. Therefore, it is possible to prevent cost increases due to the use of ECUs with excessive performance. Moreover, there is the advantage that the unit price of procurement of ECUs becomes cheaper due to mass production costs, and as a result the manufacturing cost of the vehicle is reduced.

[0040] Figure 3 illustrates the migration in the lower configuration of Figure 2. Referring to Figure 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 far left of Figure 3, when the resources of the first ECU 150 become strained, if there are sufficient resources in the second ECU 152, one of the virtual ECUs operating in the first ECU 150 is migrated 176 to the second ECU 152. By migrating the virtual ECU, the resources of the first ECU 150 become available, and the stable operation of other virtual ECUs operating in the first ECU 150 can be maintained. In other words, problems in the operation of virtual ECUs due to resource strain can be prevented.

[0041] Furthermore, in order to perform such a migration, the state of the virtual ECU (memory, contents of virtual registers, etc.) 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 contents of the physical hardware layer 170 of the second ECU 152 with the contents of the physical hardware layer 172 of the second ECU 152. In this way, even when migration occurs, the state information from before the migration is stored in the physical storage, so the virtual ECU can continue to operate. As will be described later, some virtual ECUs do not undergo migration because their operating ECU is specified or their resource allocation priority is set high. For such virtual ECUs, this synchronization process is not necessary.

[0042] In this embodiment, a controller is provided in one in-vehicle ECU cluster for the synchronization processing of state 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 second ECU 152, and for performing migration.

[0043] Figure 4 shows a first example of controller arrangement. Referring to Figure 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 different device than the first ECU 220, for example, 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, like the other virtual ECUs. In other words, the controller 240 can be called a virtual controller.

[0044] There are certain constraints on the dynamic control of the virtual ECU configuration by the controller 240. For example, sensors 230 and the like are connected to the first ECU 220. Therefore, the virtual ECU running the task for processing information from these sensors 230 and the like must reside on the first ECU 220 and cannot be migrated to the second ECU 224. Similarly, vehicle body control signal lines 232 and the like are connected to the second ECU 224. Therefore, the task for performing vehicle body control must function in the virtual ECU 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 regarding the placement of virtual ECUs and conditions regarding how to place the virtual ECUs in the first ECU 220 and second ECU 224 when the in-vehicle system 200 starts up. The storage unit 242 stores these conditions in the form of a configuration file and reads it when the controller 240 starts up. Hereinafter, the configuration will be referred to as "config" and the configuration file as "config file". An example of the contents of a config file will be described later.

[0046] Figure 5 shows another example of controller configuration. Referring to Figure 5, the in-vehicle system 300 includes an in-vehicle network 322, first ECUs 320 and 2 ECUs 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 2 ECUs 324 via the in-vehicle network 322 and is provided independently of them. In this example, the controller ECU 326 includes a storage unit 342 similar to the storage unit 242 shown in Figure 4. A programmed controller 340 is operating in the controller ECU 326. The controller ECU 326 has a storage unit 342 for storing configuration files. Unlike the first ECUs 320 and 2 ECUs 324, the controller ECU 326 does not use virtualization technology. The controller ECU 326 operates as an independent ECU, as in the conventional system.

[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] Referring to Figure 6, the destination configuration 370 lists the ECU on which each virtual ECU should operate. For example, in the case of the in-vehicle system 200 in Figure 4, virtual machine A (actually specified by the identifier of virtual machine A) operates in the first ECU 220 and cannot be migrated to the second ECU 224. Virtual machine B operates in the second ECU 224 and cannot be migrated to the first ECU 220. For virtual machines C and D, it is shown that no such ECUs are specified. Both virtual machines C and D can operate in either the first ECU 220 or the second ECU 224, and therefore can be migrated.

[0049] In this example, the information "Not specified" is written in the destination configuration 370 for virtual machines C and D, but this disclosure is not limited to that form. For example, it may be agreed that "Not specified" is the default setting for virtual ECUs not listed in the destination configuration 370. However, in this case, it is necessary to be able to identify all virtual ECUs that should be started in some way. For example, a separate configuration file listing the identifiers of all virtual ECUs may be created.

[0050] An ECU can be specified by its name, identifier, or address. Alternatively, each ECU may be associated with a predetermined symbol or number, and specified by that symbol or number. Another method is to prepare a vector with the same number of elements as the number of ECUs, associate each element with an ECU, set the value of the corresponding element to, for example, "0" for ECUs that the virtual ECU can operate, and set the value of the element corresponding to an inoperable ECU to, for example, "1", and specify using that vector. Alternatively, the array of elements in the vector can be viewed as a binary number, and the value of that number can be used for specification. In this case, the value can be represented using octal or hexadecimal representation, etc.

[0051] By using the destination configuration 370 in this way, the ECU where each virtual machine is running can be appropriately controlled.

[0052] Figure 7 shows an example of the contents of the priority configuration 372. Referring to Figure 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 implemented by the virtual ECU have different priorities, such as functions that require high reliability, functions that are necessary for the vehicle but do not require such 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 core functions and require high reliability. Additional functions such as power window control and infotainment have relatively high priority and are desirable for the vehicle, but do not require such high reliability. Furthermore, functions with relatively low priority, such as those called infotainment functions, cannot be considered core functions of the vehicle and are not essential.

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

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

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

[0056] Referring to Figure 8, in this example, the initial resource specification configuration 374 describes the physical resources (number of CPU (Central Processing Unit) cores, memory size, etc.) that should be allocated to each virtual ECU when it starts up. As will be described later, the controller refers to the contents of this initial resource specification configuration 374 to determine the optimal placement of the virtual ECUs. After the in-vehicle system starts up, the placement of the virtual ECUs changes dynamically according to the resource usage of each ECU. Therefore, in this embodiment, the initial resource specification configuration 374 shown in Figure 8 is used solely to determine the placement of the virtual ECUs when the in-vehicle system starts up. Of course, it is also possible to use the initial resource specification configuration 374 to maintain the initial placement as much as possible while dynamically changing the resource placement.

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

[0058] First, let's explain migration. Migration is the process of transferring a virtual ECU operating on one ECU to another ECU within the same ECU cluster. During this process, the operation of other virtual ECUs in the ECU cluster does not stop, but the virtual ECU being migrated is stopped for a brief moment (a few milliseconds). Therefore, migration should not be performed on virtual ECUs that require high reliability. Also, virtual ECUs whose operating ECU is specified cannot be migrated. Therefore, in this embodiment, the following restrictions are imposed. By imposing the following restrictions, virtual ECUs that are of low importance and do not depend on a device can be actively migrated. As a result, the load on each ECU can be distributed, and stable operation of virtual ECUs can be achieved on each ECU.

[0059] High priority virtual ECU... Migration not possible Virtual ECU with "medium" priority... Migration possible Virtual ECU with "low" priority... Migration possible Virtual ECU with specified deployment location... Migration not possible Virtual ECU with no specified destination…Migration possible

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

[0061] Meanwhile, in virtual machine B420, virtual machines B and C are running, with resource utilization rates of 40% and 55%, respectively. There are 5% of free resources. The controller is programmed to determine that the ECU's resources are strained when the amount of free resources in the ECU falls below a predetermined threshold (e.g., 15%). Then, in the state shown in Figure 9, the second ECU 412 will be determined to be strained.

[0062] In the example shown in Figure 9, let's assume that both virtual machine B and virtual machine C are allowed to migrate. In this case, the controller determines which virtual ECU to migrate so that the resource allocation after migration is as level as possible. Specifically, in the example shown in Figure 9, virtual machine B420 is migrated from the second ECU412 to the first ECU410422. As a result, the available resources in the first ECU410 decrease by 30%, but resources do not become strained, and the available resources in the second ECU412 increase to 45%, allowing virtual machine C to operate stably.

[0063] If migration 422 shown in Figure 9 alone would inevitably lead to a resource shortage in the first ECU 410 or the second ECU 412, the controller will perform a resource reduction process (resource reduction process) to reduce the resource allocation to the virtual ECU.

[0064] The resource reduction process is described below. Note that resource reduction affects the performance of the target virtual ECU. Therefore, the following restrictions are imposed on resource allocation and reduction.

[0065] High-priority virtual ECUs: Unlimited resource usage. Not subject to resource reduction. Virtual ECUs with a "medium" priority: Resources can be used without restriction. Not subject to resource reduction. Low-priority virtual ECUs... can use resources as long as resources are available. However, they are subject to resource reduction when resources are scarce.

[0066] Figure 10 shows an overview of the resource allocation process. Referring to the left side of Figure 10, for example, in ECU 430, the resource utilization rate by the high-priority virtual machine A has become high at 60%, resulting in the available resources 440 falling below the threshold at 5%, and resource congestion is detected. Virtual machine A may request further resources. In this case, there may not be enough available resources in other ECUs, and it may not be possible to migrate the low-priority virtual machine B to another ECU. In such cases, as shown on the right side of Figure 10, an attempt is made to alleviate the resource congestion by reducing the resources allocated to the low-priority virtual machine B, thereby raising the amount of available resources 442 above the threshold (for example, 20%).

[0067] Methods for reducing allocated resources include, in the case of CPUs, reducing the number of allocated cores. In the case of memory, methods such as memory ballooning, memory swapping, and memory compression can be used.

[0068] C. Hardware and Software Figure 11 shows a block diagram of the hardware configuration for realizing the 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 the specific configurations of these clusters (such as the number of ECUs and the number of virtual machines running) may differ from one another, the basic configuration is common. Therefore, the configuration and operation of the first ECU cluster 452 will be described below.

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

[0070] ECU460 is essentially a computer and includes a CPU482, main memory 484, auxiliary memory 486, input / output interface (I / F) 488, in-vehicle network communication unit 490, and a bus 480 that connects all of these components to each other for communication. The I / F 488 receives signals from various devices 464, such as cameras, and CAN (Controller Area Network) signals. The in-vehicle network communication unit 490 is an interface for ECU460 to the in-vehicle network 462. ECU460 can communicate with all other ECUs belonging to multiple 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 auxiliary memory 486. When the CPU 482 executes a program, it reads the program from a specified address in auxiliary memory 486. The CPU 482 loads the program into main memory 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 decoding 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 execution results of the instructions. The CPU 482 reads a new instruction from the address in main memory 484 specified by the updated program counter and executes it. By performing these processes, the CPU 482 realizes the functions defined by the program.

[0072] In this embodiment, it is assumed that the CPU482 has multiple cores and is capable of executing speculative instructions. As a result, various processes can be executed at high speed.

[0073] The virtual ECU is essentially a file installed in auxiliary storage device 486. The virtualization program, also installed in auxiliary storage device 486, is loaded into main memory device 484 and executed by CPU 482. This virtualization program reads the virtual ECU file and emulates the CPU according to its contents, 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, it is not limited to a hypervisor; a virtualization program that runs on top of the host OS may also be used.

[0074] The following describes the control structure of the program that implements the controller's functions in this embodiment. Here, the controller is assumed to be an application that runs on the host CPU, not in a virtualized environment, on a dedicated computer, the controller ECU326, as shown in Figure 5. This program starts when the controller ECU326 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 processes described below, detecting and executing any processing requests related to the maintenance of virtual machines (such as migration and resource reduction requests) in real time. Real-time execution here refers to what is known as real-time processing in information processing technology. Real-time processing is a concept in contrast to batch processing and means processing immediately when any processing request occurs.

[0075] Referring to Figure 12, the controller program, immediately after startup, includes steps 500 to read the virtual ECU destination configuration 370 (Figure 6), step 502 to read the virtual ECU priority configuration 372 (Figure 7), and step 504 to read the virtual ECU initial resource configuration 374 (Figure 8). The controller program stores the information read from these configuration files into variables within the program.

[0076] This program further includes a step 506, after step 504, which starts all virtual ECUs. Starting all virtual ECUs requires the information read in steps 500, 502, and 504 described above.

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

[0078] The program further includes step 510, which terminates all virtual ECUs and ends the execution of the controller program after the in-vehicle system is instructed to shut down and the processing of step 508 is completed.

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

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

[0081] This program further includes step 538, which, when the determination in step 536 is negative, branches the control flow according to whether or not there exists an arrangement pattern in which the CPU usage is less than or equal to a third default value, and step 540, which, when the determination in step 538 is negative, branches the control flow according to whether or not there exists an arrangement pattern in which the memory usage is less than or equal to a fourth default value. In this embodiment, the third default value is the same as the first default value in step 536. However, they do not necessarily have to be the same. For example, the third default value may be less than or equal to the first default value. Similarly, in this embodiment, the fourth default value is the same as the second default value, but they do not have to be the same. For example, the fourth default value may be less than or equal to the second default value.

[0082] This program includes, if the determination in step 536, 538, or 540 is affirmative, step 542 which narrows down the placement patterns to those that meet the conditions specified in those steps, and step 544 which selects from the remaining placement patterns in step 542 the placement pattern with the smallest difference in CPU usage among all ECUs. This program further includes step 546 which distributes the virtual ECUs to each ECU according to the placement pattern selected in step 544, starts all virtual ECUs, and terminates step 506.

[0083] If the determination in step 540 is negative, the process for when a suitable placement for the virtual ECU cannot be found is executed in step 548. In step 548, for example, the configuration file may be modified so that low-priority virtual ECUs are not started, and step 506 may be executed again. Alternatively, the resources allocated to low-priority virtual ECUs may be uniformly reduced, and step 506 may be executed again. In some cases, a message may be displayed indicating that the virtual ECU cannot be started, and instructions from the user may be sought.

[0084] In step 544, the "difference" in "the arrangement pattern with the smallest difference in CPU usage" can be any of the following: the range of CPU usage (the difference between the maximum and minimum values), the mean deviation, or the variance, after calculating the CPU usage for each arrangement pattern for all ECUs.

[0085] Referring to Figure 14, step 508 in Figure 12 includes step 600, which monitors the resource utilization of each ECU, and step 602, which branches the control flow depending on whether or not there are any ECUs experiencing resource congestion as a result of the monitoring in step 600. The determination in step 602 is positive, for example, if the CPU utilization or memory utilization 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 re-executed.

[0086] This program further includes step 604, which, if the determination in step 602 is positive, migrates one of the virtual ECUs operating in the ECU determined to be under resource strain to another ECU. The details of the process in step 604 will be described later with reference to Figure 15.

[0087] This program further includes step 606, which branches the control flow after step 604 depending on whether the resource congestion has been resolved. The determination in step 606 is made based on whether the resource utilization rate in all ECUs of the in-vehicle system is below a specified value. If the determination in step 606 is positive, control returns to step 600 and resource monitoring resumes. This program further includes step 608, which is executed in response to a negative determination in step 606, and reduces the resources of low-priority machines. After this, control returns to step 600. The contents of step 608 will be described later with reference to Figure 16. Thus, in this embodiment, the controller constantly monitors whether resource congestion is occurring by comparing various indicators with specified values. If the result of the comparison between the indicators and specified values ​​indicates that resource congestion is occurring, the controller determines that it is necessary to resolve the congestion and immediately executes the necessary processing.

[0088] The control structure of the program that performs the migration in step 604 will be explained with reference to Figure 15. Step 604 includes step 650, which branches the control flow depending on whether or not there are medium- or low-priority virtual ECUs running in the resource-constrained ECU. If the determination in step 650 is negative, the execution of step 604 is terminated.

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

[0090] Step 604 further includes step 656, which branches the control flow depending on whether or not there exists a combination in step 654 in which both CPU usage and memory usage are below a specified value, and step 658, which terminates step 604 by performing the migration of the target virtual ECU to realize the combination found in step 656, if the determination in step 656 is positive. The specified value for CPU usage in step 656 is set to the fifth specified value, and the specified value for memory usage is set to the sixth specified value.

[0091] Step 604 further includes, if the determination in step 656 is negative, step 660 which branches the control flow according to whether or not there is a combination in which the CPU usage is less than or equal to the seventh specified value, and, if the determination in step 660 is positive, step 662 which terminates step 604 by performing the migration of the target virtual ECU to realize the combination found in step 660.

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

[0093] In steps 658 and 662 or step 664, if there are multiple possible combinations, the same criteria as in step 544 of Figure 13 may be used to select the combination.

[0094] Referring to Figure 16, step 608 in Figure 14 includes step 700, which extracts all low-priority machines running in the ECU (target ECU) where resource congestion is detected; step 702, which branches the control flow according to whether the CPU usage of the target ECU is equal to or greater than the ninth specified value; and step 704, which, if the determination in step 702 is positive, uniformly reduces the CPU usage of all low-priority machines running in the target ECU by a fixed amount. If the determination in step 702 is negative, the control proceeds to step 706.

[0095] Step 608 further includes, after step 704, step 706, which branches the control flow according to whether the memory usage rate in the target ECU is equal to or greater than the 10th specified value, and, if the determination in step 706 is positive, step 708, which reduces the memory usage of all low-priority machines in the target ECU by a fixed percentage (or a fixed amount) and terminates the execution of step 608. If the determination in step 706 is negative, the execution of step 608 is terminated.

[0096] 2. Operation The first ECU cluster 452 (Figure 11), which has the configuration described above, operates as follows.

[0097] A. At startup Referring to Figure 11, when the in-vehicle system 450 is powered on, the ECU 460 and multiple ECUs 466 of the first ECU cluster 452 start up. In each of the multiple ECUs 466, the hyperpizer starts up and waits for a start command for the virtual ECU.

[0098] The ECU460, which operates as a controller ECU, operates as follows. Note that the destination configuration 370, priority configuration 372, and initial resource configuration 374 are all stored in the auxiliary storage device 486.

[0099] Referring to Figure 12, the ECU 460 reads the destination configuration 370, priority configuration 372, and initial resource configuration 374 from the auxiliary storage device 486 (steps 500, 502, and 504), and assigns the respective specified values ​​to the predetermined variables of the program.

[0100] Referring to Figure 13, ECU 460 calculates resource utilization for each possible placement pattern of the virtual ECU by performing steps 530, 532, and 534. Furthermore, in step 536, 538, or 540, if there is a virtual ECU placement pattern that meets the conditions, step 542 narrows down the virtual ECU placement patterns to that pattern. Furthermore, in step 544, ECU 460 calculates the CPU utilization in each ECU for the virtual ECU in the first ECU cluster 452 for each of the remaining placement patterns. Furthermore, for each placement pattern, ECU 460 selects the placement pattern with the smallest difference in CPU utilization in each ECU. In step 546, ECU 460 allocates and starts each virtual ECU to its respective ECU according to the selected placement pattern, and terminates the process in step 506.

[0101] B. Monitoring and resource adjustment Returning to Figure 12, ECU460 begins the resource optimization process in step 508. Referring to Figure 14, ECU460 monitors the resources in each ECU. Specifically, ECU460 calculates the CPU usage and memory usage in each ECU.

[0102] In step 602, ECU460 determines whether or not there are any ECUs experiencing resource congestion. If no such ECUs exist, control returns to step 600, and ECU460 resumes resource monitoring. If there are any ECUs experiencing resource congestion, ECU460 executes the migration process shown in Figure 15 in step 604.

[0103] Referring to Figure 15, in the migration process of step 604, ECU460 selects a low-priority machine that can be migrated and is running on the ECU (target ECU) where resource congestion was detected in step 602 of Figure 14. ECU460 further extracts all feasible migration patterns for the medium and low-priority machines extracted in step 652 in step 654. Also in step 654, ECU460 calculates the resource utilization rate after migration for each of the extracted migration patterns. Based on this resource utilization rate prediction, feasible migrations are executed in steps 656, 658, 660, 662, 664, and 666. If the resource congestion is not resolved by the resource utilization rate prediction even after migration, the judgments in steps 656, 660, and 664 will all be negative, and the migration will not be executed.

[0104] Referring again to Figure 14, if the resource congestion is resolved as a result of executing step 604, the determination in step 606 will be positive and the resource optimization process will end. If the resource congestion is not resolved, step 608 will be executed.

[0105] Referring to Figure 16, in step 608, if the CPU usage in an ECU where resource congestion is detected is greater than or equal to the 9th specified value (the determination in step 702 is positive), the CPU usage of all low-priority machines running on that ECU is uniformly reduced (step 704). Furthermore, if the memory usage in that ECU is greater than or equal to the 10th specified value (the determination in step 706 is positive), the memory usage of all low-priority machines running on that ECU is reduced.

[0106] If the determination in step 702 is negative, the resource reduction process is not 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 by multiple ECUs, and the controller manages the virtual ECUs running in each ECU. In this management, when a resource shortage occurs in an ECU, the controller resolves the resource shortage in that ECU by migrating the virtual ECU from that ECU to another ECU. If the resource shortage is not resolved even after 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 utilize those resources. By performing this management, the controller dynamically redistributes the load on the ECUs and maintains the functionality of the in-vehicle system.

[0108] Second variation The above embodiment assumes that there is one ECU cluster in the in-vehicle system. However, this disclosure is not limited to such embodiments. The in-vehicle system may have multiple ECU clusters. In this case, each ECU cluster has its own controller and independently performs dynamic load redistribution in each ECU cluster. 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] Furthermore, in the above embodiment, information regarding the virtual ECU in each ECU is synchronized among the ECUs. However, this disclosure is not limited to such embodiments. Such synchronization may be performed immediately before migration rather than at all times.

[0110] In the above embodiment, the placement configuration information for the virtual ECU is described in three configuration files. However, this disclosure is not limited to such embodiments. The placement configuration information may be described in one configuration file, two, or four or more configuration files. Furthermore, the placement configuration information for the virtual ECU does not need to be described in a file. The placement configuration information may be stored in a database, for example. This database may be provided for each ECU cluster, or there may be only one database for the entire in-vehicle system. If there is only one database for the entire in-vehicle system, it is necessary to assign an identifier to each ECU cluster and provide a field for that identifier in each record of the database. Alternatively, the placement configuration information for these virtual ECUs may be described together as literals within the source program of the controller program. In this case, it becomes necessary to compile the controller program, but it is easy to change the contents of the placement configuration information. Furthermore, a program may be created separately from the controller program that, when called, returns the placement configuration information for that ECU cluster, or a pointer to its storage address, in a certain format. In this case, recompilation of the controller program itself is not required.

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

[0112] The embodiments disclosed herein should be considered in all respects to be illustrative and not restrictive. The scope of this disclosure is not defined by the description in the detailed disclosure but by the claims, and all modifications within the meaning and scope equivalent to the wording of the claims are intended. [Explanation of symbols]

[0113] 42, 100, 430, 460 ECU 60, 170, 172 Physical Hardware Layers 62 Virtualization Infrastructure Layer 64 virtual machine tiers 110, 150, 220, 320, 410 1st ECU 112, 152, 224, 324, 412 2nd ECU 140,400 In-vehicle ECU cluster 154 Synchronization Processing Unit 176,422 migrations 200, 300, 450 In-vehicle systems 222, 322, 462 In-vehicle networks 230 sensors 232 Signal line for vehicle control 240, 340 controllers 242, 342 Storage section 326 Controller ECU 370 Destination Specification Configuration 372 Priority Configuration 374 Initial Resource Specification Configuration 420 Virtual Machine B 440, 442 free resources 452 1st ECU cluster 454 Second ECU cluster 456 Third ECU cluster 464 Various Devices 466 Multiple ECUs 480 bus 482 CPU 484 Main storage 486 Auxiliary storage 488 Input / Output Interfaces 490 In-vehicle network communication unit

Claims

1. An in-vehicle system including an information processing cluster that includes a first information processing device and a second information processing device that can communicate with each other, Each of the first information processing device and the second information processing device is: Computer hardware, and This includes a virtualization infrastructure that operates on the aforementioned computer hardware, The in-vehicle system further includes a controller for operating one or more virtual machines in the virtualization infrastructure of the first information processing device and the second information processing device. The controller monitors the usage of hardware resources in the first and second information processing devices, and changes the configuration of the one or more virtual machines in real time according to the usage of the hardware resources. The in-vehicle system includes a controller device that is included in the information processing cluster, is capable of communicating with the first information processing device and the second information processing device, and is provided independently of the first information processing device and the second information processing device.

2. The aforementioned controller, A configuration recording unit records configuration information that defines the arrangement configuration of the one or more virtual machines, 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 arrangement 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 it if necessary.

3. The aforementioned arrangement configuration information is In the one or more virtual machines, destination specification information records the virtual machine to be run on a specific destination information processing device and information specifying the specific destination information processing device. With respect to the one or more virtual machines, priority information that specifies the priority when allocating the hardware resources, Initial resource information specifying the initial allocation of hardware resources when one or more virtual machines are started, or The in-vehicle system according to claim 2, comprising at least two of the above-mentioned destination designation information, priority information, and initial resource information.

4. The aforementioned arrangement configuration information is In the one or more virtual machines, the destination specification information records the virtual machine to be run on a specific destination information processing device and information specifying the specific destination information processing device. With respect to the one or more virtual machines, the system includes priority information that specifies the priority when allocating the hardware resources, The aforementioned priority includes the highest first priority and a second priority that is lower than the aforementioned first priority. The in-vehicle system according to claim 2, wherein the placement control unit monitors the usage status of the hardware resources in the first information processing device, and in response to the detection of a shortage of hardware resources in the first information processing device, includes a destination control unit that selects a virtual machine among the virtual machines running in the first information processing device that is indicated by the destination designation information as being moveable to the second information processing device and has a priority of the second priority, and moves it to the second information processing device.

5. The in-vehicle system according to claim 4, further comprising a deployment control 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 the detection of a hardware resource shortage in the in-vehicle system even after the movement of the virtual machine by the destination control unit, reduces the allocation of the hardware resources to virtual machines whose priority is the second priority among the virtual machines running in the information processing device where the hardware resource shortage was detected.

6. An in-vehicle system according to any one of claims 1 to 5, comprising a plurality of information processing device clusters.

7. An in-vehicle system including an information processing cluster comprising a first information processing device and a second information processing device that can communicate with each other, Each of the first information processing device and the second information processing device is: Computer hardware, and This includes a virtualization infrastructure that operates on the aforementioned computer hardware, The in-vehicle system further includes a controller for operating one or more virtual machines in the virtualization infrastructure of the first information processing device and the second information processing device. The controller monitors the usage of hardware resources in the first and second information processing devices, and changes the configuration of the one or more virtual machines in real time according to the usage of the hardware resources. The aforementioned controller, A configuration recording unit records configuration information that defines the arrangement configuration of the one or more virtual machines, Includes 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 it if necessary. The aforementioned arrangement configuration information is In the one or more virtual machines, the destination specification information records the virtual machine to be run on a specific destination information processing device and information specifying the specific destination information processing device. With respect to the one or more virtual machines, the system includes priority information that specifies the priority when allocating the hardware resources, The aforementioned priority includes the highest first priority and a second priority that is lower than the aforementioned first priority. An in-vehicle system comprising: a placement control unit, which monitors the usage status of the hardware resources in the first information processing device, and in response to the detection of a shortage of the hardware resources in the first information processing device, a destination control unit that selects a virtual machine among the virtual machines running in the first information processing device that is indicated by the destination designation information as being moveable to the second information processing device and has a priority of the second priority, and moves it to the second information processing device.

8. A control method for an in-vehicle system including an information processing cluster that includes a first information processing device and a second information processing device that can communicate with each other, Each of the first information processing device and the second information processing device is: Computer hardware, and This includes a virtualization infrastructure that operates on the aforementioned computer hardware, The control method described above is The computer runs one or more virtual machines in the virtualization infrastructure of each of the first and second information processing devices, The computer performs the step of monitoring the usage status of hardware resources in the first information processing device and the second information processing device, The computer, in response to the detection of a hardware resource shortage in the first information processing device, modifies the configuration of one or more virtual machines in real time. The computer records a configuration information that defines the arrangement configuration of the one or more virtual machines. The computer includes a placement control step in which it 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 them if necessary. The aforementioned arrangement configuration information is In the one or more virtual machines, the destination specification information records the virtual machine to be run on a specific destination information processing device and information specifying the specific destination information processing device. With respect to the one or more virtual machines, the system includes priority information that specifies the priority when allocating the hardware resources, The aforementioned priority includes the highest first priority and a second priority that is lower than the aforementioned first priority. A control method for an in-vehicle system, wherein the deployment control step includes a destination control step in which the computer monitors the usage of the hardware resources in the first information processing device, and in response to the detection of a shortage of the hardware resources in the first information processing device, selects a virtual machine among the virtual machines running in the first information processing device that is indicated by the destination designation information as being moveable to the second information processing device and has the second priority, and moves it to the second information processing device.

Images