WO2024048001A1 - In-vehicle system and control method for in-vehicle system - Google Patents

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 systems and control methods for in-vehicle systems

This disclosure relates to an in-vehicle system and a method for controlling the in-vehicle system. This application claims priority based on Japanese Application No. 2022-138903 filed on September 1, 2023, and all contents described in the said Japanese application are hereby incorporated by reference.

Conventionally, a vehicle is provided with a plurality of ECUs (Electronic Control Units) that are control devices for controlling various parts of the vehicle. An ECU is essentially a computer. Therefore, the ECU is capable of interrupt processing and can appropriately respond to emergencies.

The ECU was originally used to control the engine. However, as vehicle equipment becomes more electronic, ECUs are being used in various locations. For example, the ECU is also responsible for collecting information from various sensors installed in the vehicle. The ECU is used to determine the driving state of the vehicle, control the brakes, control electrical equipment, and also for lane keeping systems, inter-vehicle distance control systems, etc.

On the other hand, the number of processes performed by ECUs in vehicles is also increasing more than the increase in the number of ECUs installed in vehicles. Therefore, there is a technique in which these processes are divided into a plurality of tasks and each task is executed by a plurality of ECUs. However, in the case of an in-vehicle ECU, the magnitude of the load on each task varies greatly depending on the situation. Therefore, it is necessary to dynamically distribute the load on the ECU.

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 allows external devices to be used transparently. When a task is migrated to another ECU, this virtual device driver is also migrated to the destination ECU. It is said that by doing this, the external device can also be used transparently in the destination ECU. Note that this migration is performed while the ECU is in operation. Such migration is called "live migration." All migrations described in this specification are live migrations, and are simply referred to as "migrations" for the purpose of brevity.

Japanese Patent Application Publication No. 2009-070135 Japanese Patent Application Publication No. 2013-003946 International Publication No. 2021/010124

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 can communicate with each other, the first information processing device and the second information processing device being able to communicate with each other. Each of the information processing devices includes computer hardware and a virtualization platform running on the computer hardware, and the in-vehicle system further includes one or more virtualization platforms of the first information processing device and the second information processing device. The controller includes a controller for operating a virtual machine, and the controller monitors the usage status of computer hardware resources in the first information processing device and the second information processing device, and depending on the usage status of the hardware resources, Change the configuration of multiple virtual machines in real time.

These and other objects, features, aspects, and advantages of this disclosure will become apparent from the following detailed description of this disclosure, taken in conjunction with the accompanying drawings.

FIG. 1 is a block diagram schematically showing 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 virtual ECUs in an ECU cluster. FIG. 4 is a block diagram showing an example of the arrangement of controllers that control the ECU cluster. FIG. 5 is a block diagram showing another example of the arrangement of controllers that control the ECU cluster. FIG. 6 is a schematic diagram illustrating an example of the contents of a configuration (setting) file specifying the 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 virtual machines between different ECUs. FIG. 10 is a schematic diagram for explaining reduction in used resources (expansion of usable resources) in a single ECU. FIG. 11 is a block diagram showing the hardware configuration of the in-vehicle system and ECU according to this disclosure. FIG. 12 is a flowchart showing the control structure of a program for resource management executed by the controller of the in-vehicle system according to the embodiment. FIG. 13 is a flowchart showing a control structure of a computer program that implements the process for starting the virtual machine shown in FIG. 12. FIG. 14 is a flowchart showing a control structure of a computer program that implements the resource optimization process shown in FIG. 12. FIG. 15 is a flowchart showing the control structure of a computer program that implements the migration shown in FIG. 14. FIG. 16 is a flowchart showing the control structure of a computer program that implements the resource reduction process shown in FIG. 14.

[Issues this disclosure seeks to solve]
With the recent development of computer technology, a virtualization platform is built on one ECU, and multiple virtual machines each using an independent OS (Operating System), BSW (Basic Software), etc. are built on this virtualization platform. It is now possible to operate. That is, one or more virtual ECUs can be operated on one ECU. As a result, a large number of ECUs used in a vehicle can be consolidated into a relatively small number of ECUs. However, even when a plurality of virtual machines are operated on such a relatively small number of ECUs, it is necessary to dynamically distribute the load on each ECU.

The technology disclosed in Patent Document 1 mentioned above is load distribution at the task level of applications. When applying the technology disclosed in Patent Document 1 to an ECU on which a virtual machine is operating, the load is distributed among a plurality of virtual ECUs operating on the ECU. Such methods cannot reduce the load on the ECU itself on which the virtual machine is operating. These problems may occur not only in the ECU but also in multiple information processing devices installed in a vehicle.

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 on which a virtual machine is running.

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

[Description of embodiments of the present disclosure]
A summary of this disclosure follows.

(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 can communicate with each other, the first information processing device Each of the information processing devices and the second information processing device includes computer hardware and a virtualization infrastructure that operates on the computer hardware, and the in-vehicle system further includes, in the virtualization infrastructure of the first information processing device and the second information processing device, The controller includes a controller for operating one or more virtual machines, the controller monitors the usage status of hardware resources in the first information processing device and the second information processing device, and depending on the usage status of the hardware resources, Change the configuration of one or more virtual machines in real time.

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 machine in real time according to the usage status 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. Since this load control can be executed independently of the load control in other information processing device clusters, dynamic control of the virtual machine load in the in-vehicle system can be easily performed.

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

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

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

The controller is realized as a virtual controller on the virtualization infrastructure of the first information processing device. There is no need to separately provide hardware for executing the controller, so the cost of the in-vehicle device can be kept low and maintenance can be facilitated.

(4) In any one of (1) to (3) above, the controller includes a layout configuration recording unit that records layout configuration information that defines a layout configuration of one or more virtual machines, and a first information processing device. and monitors the operating status of the second information processing device, and determines the placement of one or more virtual machines within the information processing device cluster in real time so that the one or more virtual machines operate stably. If so, it may include a placement control section for changing the location.

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

(5) In (4) above, the placement configuration information specifies, among one or more virtual machines, a virtual machine to be operated on an information processing device that is a specific operating destination and an information processing device that is a specific operating destination. Priority information that specifies the priority when allocating hardware resources for one or more virtual machines, Initialization of hardware resources when starting one or more virtual machines The information may include at least any two of initial resource information specifying allocation, operating destination specification information, priority information, and initial resource information.

When using the operating 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 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 initial resource information is used, the placement of virtual machines can be quickly determined when the in-vehicle system is started. There is no need to adjust the placement of virtual machines after startup, reducing the time required to start up the in-vehicle system.

(6) In (4) above, the placement configuration information specifies, among one or more virtual machines, a virtual machine to be operated on an information processing device that is a specific operating destination and an information processing device that is a specific operating destination. and priority information that specifies the priority when allocating hardware resources for one or more virtual machines, where the priority is the highest first priority. and a second priority lower than the first priority. In response to the detection of the virtual machine, among the virtual machines running on the first information processing device, the operation destination specification information indicates that the virtual machine can be moved to the second information processing device, and the priority is The information processing apparatus may include an operation destination control unit that selects a virtual machine having a second priority and moves the virtual machine to the second information processing apparatus.

A virtual machine that is moved from the first information processing device to the second information processing device when a hardware resource shortage is detected in the first information processing device is capable of being moved to the second information processing device, and 2 priority is assigned. This eliminates the possibility that a virtual machine, which is important for realizing the functions of an in-vehicle system, may be moved to an information processing device that cannot fully demonstrate its functions, and the in-vehicle system can stably perform the functions required of an in-vehicle system. I can demonstrate it.

(7) In (6) above, the placement control unit further monitors the usage status of hardware resources in the first information processing device and the second information processing device, and after the operation destination control unit moves the virtual machine. In response to the detection of hardware resource tightness in the in-vehicle system, the priority level is set to 2nd priority among the virtual machines running on the information processing device where the hardware resource tightness was detected. It may also include a resource reduction unit that reduces allocation of hardware resources to a certain virtual machine.

In some cases, even after moving a virtual machine, a hardware resource strain is detected, or the virtual machine cannot be moved and the hardware resource strain cannot be resolved. In such a case, in the information processing apparatus in which the shortage of hardware resources has been detected, the allocation of hardware resources to virtual machines with low priority is reduced. As a result, the amount of hardware resources available to high-priority virtual machines increases, allowing the performance of the in-vehicle system to be maintained.

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

Even when multiple information processing device clusters are provided, dynamic distribution of the load on the information processing devices related to the execution of 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 vehicle-mounted device increases, the functions of the vehicle-mounted system can be stably maintained.

(9) A method for controlling an in-vehicle system according to a second aspect of this disclosure is 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 that can communicate with each other. , 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 a computer controlling the first information processing device and the second information processing device. a step of operating one or more virtual machines in each virtualization platform of the processing device; a step of the computer monitoring the usage status of hardware resources in the first information processing device and the second information processing device; The method includes the step of changing the configuration of one or more virtual machines in real time in response to detection of hardware resource shortage in one information processing device.

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 in each of these information processing devices. The computer 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 machine in real time according to the usage status 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. Since this load control can be executed independently of the load control in other information processing device clusters, dynamic control of the virtual machine load in the in-vehicle system can be easily performed.

[Details of embodiments of the present disclosure]
A specific example of an in-vehicle system and a control method thereof according to an embodiment of the present disclosure will be described below with reference to the drawings. In the following description and drawings, identical parts are provided with the same reference numerals. Therefore, detailed description thereof will not be repeated. Note that the present disclosure is not limited to these examples, but is indicated by the scope of the claims, and is intended to include all changes within the meaning and scope equivalent to the scope of the claims. Moreover, one or more arbitrary features of the following embodiments may be combined.

First embodiment 1. Configuration A. ECU
FIG. 1 shows a schematic configuration of an ECU 42 according to a first embodiment of this disclosure. Referring to FIG. 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 one or more components operating in the virtualization infrastructure layer 62. It includes a virtual machine layer 64 that includes a virtual machine (virtual ECU). The virtualization infrastructure layer 62 uses a hardware resource called the physical hardware layer 60.

Each virtual ECU executes the same tasks as each conventional ECU. All of these virtual ECUs operate in the same virtual operating environment as the conventional operating environment, which is provided by the virtualization infrastructure layer 62. Therefore, the OS and each application executed by the virtual ECU are the same as the OS and applications executed by a conventional single ECU.

B. ECU Cluster As shown in FIG. 1, one ECU can operate multiple virtual ECUs. However, when a plurality of virtual ECUs are operated on each ECU, there is a possibility that the load on a particular ECU becomes excessive. It is necessary to avoid such situations from occurring.

In order to avoid such problems, this embodiment introduces the concept of an ECU cluster. An ECU cluster refers to a group consisting of a plurality of ECUs, each of which operates one or more virtual ECUs. The ECU cluster defines a range of destinations when a virtual ECU is migrated (moved) as will be described later. That is, a virtual ECU operating in an ECU within a certain ECU cluster can be migrated to another ECU within the same ECU cluster, but is not migrated to an ECU in another ECU cluster. In the ECU cluster constructed in this way, by monitoring the resource usage status of each ECU in the ECU cluster, it is possible to level out the load on each ECU in the cluster or reduce the load on each ECU. A controller will be provided for this purpose. By providing an ECU cluster, the number of ECUs and virtual ECUs managed by one controller can be made relatively small, which has the advantage of being easy to manage and quickly performing necessary processing.

Note that it is also possible to think that it is possible to avoid a situation where the load becomes excessive by increasing the scale and performance of each individual ECU without using an ECU cluster. An example based on such a concept is shown in the upper part of FIG. 2 as an ECU 100. In this example, a large number of virtual machines are operated in the ECU 100. On the other hand, an example based on the concept of ECU cluster is shown in the lower part of FIG. In the format shown in the lower part of FIG. 2, an ECU cluster is formed by a plurality of ECUs (for example, a first ECU 110 and a second ECU 112) that are smaller in size and have lower performance than the ECU 100 shown in the upper part. A plurality of virtual ECUs operate in each of the first ECU 110 and the second ECU 112. Although the performance of the ECU here is inferior to that of the ECU 100, by employing an ECU cluster as shown in the lower part of FIG. 2, it is possible to provide computation resources comparable to those in the upper part of FIG.

However, it is desirable to adopt the configuration shown in the lower part of FIG. 2 for an actual vehicle. The reason is as follows. As described above, depending on the configuration shown in the upper part of FIG. 1, when the resources of the ECU 100 become tight, it is not possible to migrate the virtual ECU to another ECU. In contrast, in the configuration shown in the lower part of FIG. 2, virtual ECUs can be migrated between ECUs belonging to the same ECU cluster. Moreover, 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, an increase in cost due to the use of an ECU with excessive performance can be prevented. Furthermore, there is an advantage that the unit cost of ECU procurement is reduced due to the mass production cost, and as a result, the manufacturing cost of the vehicle is reduced.

FIG. 3 describes migration in the configuration shown in the lower part of FIG. 2. Referring to FIG. 3, it is assumed that in-vehicle ECU cluster 140 includes first ECU 150 and 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 at the left end of FIG. 3, when the resources of the first ECU 150 are tight, if the resources of the second ECU 152 are available, one of the virtual ECUs operating in the first ECU 150 is migrated 176 to the second ECU 152. . By migrating the virtual ECU, resources of the first ECU 150 are freed up, and stable operation of other virtual ECUs operating in the first ECU 150 can be maintained. That is, it is possible to prevent problems from occurring in the operation of the virtual ECU due to tight resources.

Note that in order to perform such migration, it is also necessary to transfer the state of the virtual ECU (memory, contents of virtual registers, etc.) from the first ECU 150 to the second ECU 152. In this embodiment, instead of transferring the status information at the time of migration, by providing the synchronization processing unit 154, the storage contents of the physical hardware layer 170 of the second ECU 152 and the physical hardware layer 172 of the second ECU 152 are transferred. Always synchronize the memory contents of By doing so, even when migration occurs, the state information before migration is stored in the physical storage, so the virtual ECU can continue operating. Note that, as will be described later, some virtual ECUs do not undergo migration because the operating destination ECU is specified or the resource allocation priority is set high. There is no need to perform this synchronization process for such virtual ECUs.

In this embodiment, one in-vehicle ECU is used for the synchronization processing of state information by the synchronization processing unit 154, the monitoring of the usage status of resources of the physical hardware layers 170 and 172 in the first ECU 150 and the second ECU 152, and the execution of migration. A controller is provided in the cluster.

FIG. 4 shows a first example of the arrangement of the 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. Among these, a sensor 230 and the like are connected to the first ECU 220, for example. A device different from the first ECU 220, such as a vehicle body control signal line 232, is connected to the second ECU 224. The first ECU 220 is provided with a controller 240 that dynamically controls the configuration of the virtual ECU in the in-vehicle system 200. Controller 240 operates as a virtual machine like other virtual ECUs. That is, controller 240 can be called a virtual controller.

There are certain restrictions on the dynamic control of the configuration of the virtual ECU by the controller 240. For example, a sensor 230 and the like are connected to the first ECU 220. Therefore, the virtual ECU in which tasks for processing information from these sensors 230 and the like are running must reside in the first ECU 220 and cannot be migrated to the second ECU 224. Similarly, a vehicle body control signal line 232 and the like are connected to the second ECU 224. Therefore, the task for controlling the vehicle body must function in the virtual ECU operating on the second ECU 224 and cannot be migrated to the first ECU 220.

The controller 240 has a storage unit 242 for storing such constraints regarding the arrangement of the virtual ECUs and conditions regarding how the virtual ECUs are arranged in the first ECU 220 and the second ECU 224 when the in-vehicle system 200 is started. . The storage unit 242 holds such conditions in the form of a configuration file, and reads the conditions when the controller 240 is started. Hereinafter, the configuration will be referred to as a "config" and the configuration file will be referred to as a "config file." An example of the contents of the configuration file will be described later.

FIG. 5 shows another example of the arrangement of the controller. Referring to FIG. 5, the 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 each can host one or more virtual ECUs; It includes a controller ECU 326 which is a controller device that is capable of communicating with the in-vehicle network 322 and the second ECU 324 via the network 322 and is provided independently from these. In this example, controller ECU 326 includes a storage section 342 similar to storage section 242 shown in FIG. In the controller ECU 326, a controller 340 implemented by a program is operating. Controller ECU 326 has a storage unit 342 for storing configuration files. 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.

In this embodiment, the storage units 242 and 342 store three types of configuration files. These are a destination specification config, a priority config, and an initial resource specification config.

Referring to FIG. 6, the operation destination specification config 370 lists the ECUs each of which should operate for all virtual ECUs. For example, in the case of the in-vehicle system 200 in FIG. 4, the virtual machine A (actually specified by the identifier of the 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 machine C and virtual machine D, it is shown that no such ECU is specified. Virtual machine C and virtual machine D can both operate on either the first ECU 220 or the second ECU 224, and therefore can be migrated.

Note that in this example, the information "not specified" is written in the operation destination specification configuration 370 for the virtual machines C and D, but this disclosure is not limited to such a form. For example, it may be determined that virtual ECUs that are not listed in the destination designation configuration 370 are designated as "not specified" as the default. However, in this case, it is necessary to be able to grasp all the virtual ECUs to be activated in some way. For example, a configuration file listing the identifiers of all virtual ECUs may be provided separately.

The ECU can be specified using the ECU name, identifier, or address. Each ECU may be associated with a predetermined symbol or number and designated by that symbol or number. Prepare a vector with elements equal to the number of ECUs, associate each element with the ECU, set the value of the corresponding element to "0" for ECUs where the virtual ECU can operate, and set the value of the corresponding element to "0" for ECUs that cannot operate. The value of the corresponding element may be set to, for example, "1" and specified by that vector, or the array of elements of the vector may be viewed as a binary number and specified using that value. In this case, the value may be expressed in octal or hexadecimal notation.

By using the operating destination designation config 370 in this way, it is possible to appropriately control the operating destination ECU of each virtual machine.

FIG. 7 shows an example of the contents of the priority configuration 372. Referring to FIG. 7, priority config 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 in-vehicle systems, the functions realized by the virtual ECU include functions that require high reliability, functions that are necessary for the vehicle but do not require high reliability, and functions that are desirable but are not essential for vehicle control. , there are features with different priorities. For example, functions such as running, turning, and stopping are related to the original functions of the vehicle and require high reliability. Additional functions such as power window control and infotainment that have a relatively high priority are desirable functions to have in the vehicle, but they do not require very high reliability. Furthermore, among the so-called infotainment functions, those with relatively low priority cannot be said to be the original functions of the vehicle and are not essential.

As mentioned above, it is necessary to allocate resources preferentially to virtual ECUs for realizing 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 those functions. Therefore, the priority config 372 describes the priority for each virtual ECU.

Note that in this example, there are three levels of priority. However, this disclosure is not limited to such embodiments. There are cases in which two levels of priority are sufficient, and cases in which four or more levels are necessary.

FIG. 8 shows an example of the contents of the initial resource specification configuration 374. When starting the in-vehicle system, it is necessary to start each virtual ECU. It is desirable that the arrangement of the virtual ECUs at the time of startup be optimized while adhering to the above-described constraints. Conditions for this are described in the initial resource specification configuration 374. That is, when the in-vehicle system is started, initial allocation of resources to each virtual ECU is executed according to the description in the initial resource designation configuration 374.

Referring to FIG. 8, for example, in this example, the initial resource specification configuration 374 includes physical resources (the number of CPU (Central Processing Unit) cores, memory size, etc.) to be allocated when each virtual ECU is started. It is described for each ECU. As will be described later, the controller refers to the contents of this initial resource specification configuration 374 and determines the optimal arrangement of virtual ECUs. Note that after the in-vehicle system is started, the arrangement of the virtual ECUs changes dynamically depending on the usage status of resources in each ECU. Therefore, in this embodiment, the initial resource designation configuration 374 shown in FIG. 8 is only used to determine the placement of the virtual ECU at the time of starting the in-vehicle system. Of course, the initial resource specification configuration 374 can also be used to dynamically change the resource placement while maintaining the initial placement as much as possible.

Note that in this embodiment, the controller performs two types of processing, migration and resource reduction, on the virtual ECU after the in-vehicle system is started. These will be explained below.

First, let's explain migration. Migration refers to moving a virtual ECU operating in a certain ECU to another ECU within the same ECU cluster. At this time, the operations of other virtual ECUs in the ECU cluster are not stopped, but the virtual ECU to be migrated is stopped for a moment (about several milliseconds). Therefore, migration should not be performed on virtual ECUs that require high reliability. Furthermore, a virtual ECU for which the operating destination ECU is specified cannot be migrated. Therefore, in this embodiment, the following restrictions are provided. By setting the following restrictions, virtual ECUs that are of low importance and do not depend on devices can be actively migrated. As a result, the load related to each ECU can be distributed, and stable operation of the virtual ECU can be realized in each ECU.

Virtual ECU with "high" priority...migration not possible Virtual ECU with "medium" priority...migration possible Virtual ECU with "low" priority...migration possible Virtual ECU with destination specified...migration not possible Virtual ECU without destination specified …migration possible

Referring to FIG. 9, it is assumed that in-vehicle ECU cluster 400 includes first ECU 410 and 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 operating in the first ECU 410. Therefore, free resources are 70%. Note that the "resource occupancy rate" is a concept that combines the CPU occupancy rate and the memory occupancy rate. How to calculate the resource occupancy rate differs depending on the designer's idea.

On the other hand, in the virtual machine B420, virtual machine B and virtual machine C are operating, and their resource occupancy rates are assumed to be 40% and 55%, respectively. Free resources are 5%. Assume that the controller is programmed to determine that the ECU's resources are tight when the amount of free resources of the ECU becomes less than a predetermined threshold (for example, 15%). Then, in the case of the state shown in FIG. 9, it is determined that resources are tight in the second ECU 412.

In the example shown in FIG. 9, it is assumed that migration is permitted for both virtual machine B and virtual machine C, for example. In this case, the controller determines the virtual ECU to be migrated so that the distribution of resources after migration is as leveled as possible. That is, in the example shown in FIG. 9, the virtual machine B420 is migrated 422 from the second ECU 412 to the first ECU 410. As a result, the free resources of the first ECU 410 decrease by 30%, but the resources are not strained, and the free resources of the second ECU 412 increase to 45%, making it possible to stably maintain the operation of the virtual machine C.

If a situation where the resources of the first ECU 410 or the second ECU 412 become strained cannot be avoided by only the migration 422 shown in FIG. 9, the controller executes a process of reducing resource allocation to the virtual ECU (resource reduction process).

The resource reduction process will be explained below. Note that resource processing reduction affects the performance of the target virtual ECU. Therefore, the following restrictions are set for resource allocation and reduction.

Virtual ECU with "high" priority...Resources can be used without restrictions. Not subject to resource reduction Virtual ECUs with medium priority...Resources can be used without restrictions. Not subject to resource reduction Virtual ECUs with "low" priority...Resources can be used as long as there are resources. However, when resources are tight, resources are subject to reduction.

FIG. 10 shows an outline of the resource allocation process. Referring to the left side of FIG. 10, for example, in the ECU 430, the resource occupancy rate by virtual machine A with a high priority is as high as 60%, and as a result, the free resource 440 becomes 5%, which is less than the threshold value, and resource strain is detected. It shall be assumed that Virtual machine A may request further resources. At this time, there may be cases where the other ECUs do not have sufficient free resources and the virtual machine B, which has a low priority, cannot be migrated to the other ECUs. In such a case, in this embodiment, as shown on the right side of FIG. 10, by reducing the resources allocated to the virtual machine B with a low priority, the amount of free resources 442 is increased to a threshold value or more ( For example, 20%), an attempt is made to resolve the resource strain.

In the case of a CPU, one method for reducing allocated resources is to reduce the number of allocated cores. In the case of memory, techniques include so-called memory ballooning, memory swapping, and memory compression.

C. Hardware and Software FIG. 11 shows, in block diagram form, the hardware configuration that implements the in-vehicle system 450 according to this embodiment. Referring to FIG. 11, 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. These clusters may have different specific configurations (the number of ECUs, the number of operating virtual machines, etc.), but the basic configuration is common. Therefore, the configuration and operation of the first ECU cluster 452 will be described below.

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, the ECU 460 and each of the plurality of ECUs 466 are of the same standard. Further, the ECU 460 can be used as an ECU that provides a virtual infrastructure, and can also be used as a controller ECU. In the following description, the ECU 460 is assumed to be a controller ECU, and the virtual ECUs are assumed to operate in a plurality of ECUs 466.

The ECU 460 is essentially a computer, and includes a CPU 482, a main storage device 484, an auxiliary storage device 486, an input/output I/F (Interface) 488, and an in-vehicle network communication section 490, all of which are communicably connected to each other. bus 480. The input/output I/F 488 receives signals from various devices 464 such as a camera, CAN (Controller Area Network) signals, and the like. The in-vehicle network communication unit 490 is an I/F for the in-vehicle network 462 for the ECU 460. ECU 460 can communicate with all other ECUs belonging to the plurality of ECUs 466 via in-vehicle network communication section 490 and in-vehicle network 462.

The program executed by the CPU 482 is stored in the auxiliary storage device 486. When CPU 482 executes a program, it reads the program from a specified address in auxiliary storage device 486. The CPU 482 loads the program into the main storage device 484, reads and executes instructions from the specified address. 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 instructions. The CPU 482 reads a new instruction from the address in the main storage device 484 specified by the updated program counter and executes it. By executing these processes, the CPU 482 realizes the functions defined by the program.

Note that this embodiment assumes that the CPU 482 has multiple cores and is also capable of executing speculative instructions. As a result, various processes can be executed at high speed.

The entity of the virtual ECU is a file installed in the auxiliary storage device 486. The virtualization program, which is 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 its contents, thereby realizing the virtual ECU. Specifically, it is desirable to use a type of virtualization program called a hypervisor that directly provides access to the computer's hardware resources without going through the host OS. Of course, not only the hypervisor but also a virtualization program running on the host OS may be used.

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

Referring to FIG. 12, immediately after startup, the controller program secures and initializes a storage area, initializes various control variables, etc., and then reads the virtual ECU operating destination designation configuration 370 (FIG. 6). The process includes step 500, step 502 of reading the virtual ECU's priority configuration 372 (FIG. 7), and step 504 of reading the virtual ECU's initial resource specification configuration 374 (FIG. 8). The controller program stores the information read from these configuration files in each variable within the program.

This program further includes, after step 504, step 506 of activating all virtual ECUs. In order to start all virtual ECUs, the information read in steps 500, 502, and 504 described above is required.

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

This program further includes step 510 of terminating all virtual ECUs and terminating the execution of the controller program after the in-vehicle system is instructed to stop and the process of step 508 is completed.

Referring to FIG. 13, step 506 of activating the virtual ECU includes a step 530 of extracting all virtual ECU placement patterns specified by the operating destination specification config 370, and a step 530 of extracting all virtual ECU placement patterns specified by the operation destination specification configuration 370, and a Step 532 of narrowing down the layout pattern to a layout pattern that minimizes the number of high-priority machines.

This program further includes step 534 of calculating the resource usage rate in each ECU for each of the placement patterns remaining in step 532 based on the contents of the initial resource specification config 374. As mentioned above, the resource usage rate referred to here is a concept that combines the CPU usage rate and the memory usage rate. This program further includes a step 536 in which the flow of control is branched depending on whether there is an arrangement 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 the first specified value, which is the specified value of the memory usage rate, and the second specified value, which is the specified value of the memory usage rate. These two types of specified values do not need to be the same. Note that in the following description, multiple types of specified values appear, but these values may be the same or different.

This program further includes a step 538 in which, when the determination in step 536 is negative, the flow of control is branched depending on whether there is an arrangement pattern in which the CPU usage rate is equal to or less than a third specified value; and a determination in step 538. is negative, branching the flow of control according to whether or not there is an arrangement pattern in which the memory usage rate 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 less than or equal to the first specified value. Similarly, although in this embodiment the fourth specified value is the same as the second specified value, they need not be the same. For example, the fourth specified value may be less than or equal to the second specified value.

When the determination in step 536, 538, or 540 is affirmative, this program narrows down the layout patterns to those that meet the conditions specified in these steps, step 542, and selects all ECUs from the remaining layout patterns in step 542. and step 544 of selecting an arrangement pattern with the smallest difference in CPU usage between the two. The program further includes a step 546 that allocates the virtual ECUs to each ECU according to the placement pattern selected in step 544, activates all virtual ECUs, and ends step 506.

If the determination in step 540 is negative, processing in the case where an appropriate placement for the virtual ECU is not found is executed in step 548. In step 548, for example, the configuration file may be changed so that the virtual ECU with low priority is not activated, and step 506 may be executed again. Alternatively, it is also possible to uniformly reduce the allocated resources for low priority virtual ECUs and execute step 506 again. Depending on the situation, it may be possible to display that the virtual ECU cannot be started and to receive instructions from the user.

Note that the "difference" in the "placement pattern with the smallest difference in CPU usage rate" in step 544 is the CPU usage rate in each of the layout patterns after calculating the CPU usage rate in each layout pattern for all ECUs. Any of the range (difference between maximum and minimum value), average deviation, or variance may be used.

Referring to FIG. 14, step 508 in FIG. 12 includes step 600 of monitoring the resource usage rate of each ECU, and control according to whether or not there is an ECU whose resources are strained as a result of the monitoring in step 600. step 602 of branching the flow of the flow. The determination in step 602 becomes positive, for example, when the CPU usage rate of a certain ECU exceeds a specified value or the memory usage rate exceeds a specified value. If the determination in step 602 is negative, control returns to step 600 and resource monitoring is performed again.

This program further includes step 604, when the determination in step 602 is positive, migrating any of the virtual ECUs operating in the ECU determined to be under resource pressure to another ECU. The details of the process in step 604 will be described later with reference to FIG. 15.

The program further includes, after step 604, step 606 of branching the flow of control depending on whether resource pressure has been resolved. The determination in step 606 is made according to whether the resource usage rate in all ECUs of the in-vehicle system is equal to or less than a specified value. If the determination in step 606 is positive, control returns to step 600 and resource monitoring is resumed. The program further includes step 608, executed in response to the negative determination in step 606, to reduce resources on the low priority machine. After this, control returns to step 600. The details of step 608 will be described later with reference to FIG. As described above, in this embodiment, the controller constantly monitors whether or not resource strain is occurring by comparing various indicators with prescribed values. If the result of the comparison between the index and the specified value indicates that resource strain has occurred, the controller determines that it is necessary to relieve the strain, and immediately executes processing for that purpose.

The control structure of the program that executes migration in step 604 will be explained with reference to FIG. 15. Step 604 includes step 650 of branching the flow of control depending on whether there is a medium- or low-priority virtual ECU operating in the resource-constrained ECU. If the determination in step 650 is negative, execution of step 604 ends.

Step 604 further includes, when the determination in step 650 is positive, a step 652 of extracting the migratable virtual ECU, and extracting all executable migration patterns for the virtual ECU extracted in step 652. and step 654 of calculating a predicted post-migration resource usage rate for each pattern.

Step 604 further includes a step 656 in which the flow of control is branched depending on whether or not there is a combination in which both the CPU usage rate and the memory usage rate are equal to or less than a specified value as a result of the processing in step 654, and the determination in step 656 is performed. If affirmative, step 658 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 usage rate in step 656 is set as the fifth specified value, and the specified value of the memory usage rate is set as the sixth specified value.

Step 604 further includes a step 660 in which, when the determination in step 656 is negative, the flow of control is branched depending on whether a combination exists in which the CPU usage rate is equal to or less than a seventh predetermined value; If the answer is yes, the step 662 executes migration of the target virtual ECU so as to realize the combination found in step 660, and ends step 604.

Step 604 further includes a step 664 in which, when the determination in step 660 is negative, the flow of control is branched depending on whether there is a combination in which the memory usage rate is equal to or less than an eighth predetermined value; and step 666, in which the target virtual ECU is migrated so as to implement the combination found in step 664, and step 604 is ended. If the determination in step 664 is negative, step 604 is ended without migration.

In steps 658 and 662 or step 664, if there are multiple possible combinations, the combinations may be selected using criteria similar to step 544 in FIG.

Referring to FIG. 16, step 608 in FIG. 14 includes step 700 of extracting all low-priority machines operating in the ECU (target ECU) in which resource tightness has been detected, and Step 702 of branching the flow of control according to whether or not it is equal to or greater than a ninth specified value; and when the determination in step 702 is positive, uniformly keeping the CPU usage of all low-priority machines operating in the target ECU constant; and step 704 of reducing the amount by the amount. If the determination in step 702 is negative, control proceeds to step 706.

Step 608 further includes, after step 704, a step 706 in which the flow of control is branched depending on whether the memory usage rate in the target ECU is equal to or higher than a tenth specified value, and when the determination in step 706 is affirmative, the control flow in the target ECU is branched. Step 708 includes uniformly reducing the memory usage of all low-priority machines by a certain percentage (or a certain amount) and ending the execution of Step 608. When the determination in step 706 is negative, execution of step 608 ends.

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

A. At Startup Referring to FIG. 11, when the power of in-vehicle system 450 is turned on, ECU 460 of first ECU cluster 452 and a plurality of ECUs 466 are started. In each of the plurality of ECUs 466, the hyperpizer is activated and enters a state in which it waits for an instruction to activate the virtual ECU.

The ECU 460 that operates as a controller ECU operates as follows. It is assumed that the operation destination specification config 370, the priority config 372, and the initial resource specification config 374 are all stored in the auxiliary storage device 486.

Referring to FIG. 12, ECU 460 reads operating destination designation config 370, priority config 372, and initial resource designation config 374 from auxiliary storage device 486 ( steps 500, 502, and 504), and sets each designated value to a predetermined variable of the program. Substitute.

Referring to FIG. 13, ECU 460 calculates the resource usage rate for each possible arrangement pattern of virtual ECUs by executing steps 530, 532, and 534. Further, in steps 536, 538, or 540, if there is a virtual ECU arrangement pattern that meets the conditions, then in step 542, the virtual ECU arrangement pattern is narrowed down to that arrangement pattern. Furthermore, in step 544, the ECU 460 calculates the CPU usage rate of each virtual ECU in the first ECU cluster 452 for each of the remaining arrangement patterns. Further, for each of the layout patterns, the ECU 460 selects the layout pattern in which the difference in CPU usage rate among the ECUs is the smallest. In step 546, the ECU 460 allocates and activates each virtual ECU according to the selected arrangement pattern, and ends the process in step 506.

B. Monitoring and Resource Adjustment Returning to FIG. 12, ECU 460 starts resource optimization processing in step 508. Referring to FIG. 14, ECU 460 monitors resources in each ECU. Specifically, ECU 460 calculates the CPU usage rate and memory usage rate of each ECU.

In step 602, the ECU 460 determines whether there is an ECU whose resources are tight. If no such ECU exists, control returns to step 600 and ECU 460 resumes resource monitoring. If there is an ECU that is under resource pressure, the ECU 460 executes the migration process shown in FIG. 15 in step 604.

Referring to FIG. 15, in the migration process of step 604, ECU 460 selects a migratable low-priority machine that is operating in the ECU (target ECU) in which resource strain was detected in step 602 of FIG. . Furthermore, in step 654, ECU 460 extracts all executable migration patterns for the medium and low priority machines extracted in step 652. Further, in step 654, ECU 460 calculates the post-migration resource usage rate for each of the extracted migration patterns. Based on this resource utilization prediction, executable migrations are performed by steps 656, 658, 660, 662, 664, and 666. If the resource pressure is 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 performed.

Referring again to FIG. 14, if the resource pressure is resolved as a result of executing step 604, the determination in step 606 will be affirmative and the resource optimization process will end. If the resource pressure is not resolved, step 608 is executed.

Referring to FIG. 16, in step 608, if the CPU usage rate is equal to or higher than the ninth predetermined value in the ECU for which resource tightness has been detected (the determination in step 702 is affirmative), the ECU is operated on. The CPU usage of all low-priority machines is uniformly reduced (step 704). Furthermore, if the amount of memory used in that ECU is equal to or greater than the tenth specified value (the determination in step 706 is affirmative), the amount of memory used by all low-priority machines operating on that ECU is reduced. Ru.

If the determination in step 702 is negative, the resource reduction process is not executed 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.

As described above, according to this embodiment, a plurality of ECUs constitute an ECU cluster, and the controller manages the virtual ECUs executed in each ECU. In this management, when a resource strain occurs in an ECU, the controller migrates a virtual ECU from that ECU to another ECU to relieve the resource strain in that ECU. If the resource pressure is not resolved even after migration, the controller reduces the resources of the low-priority virtual ECU operating in that ECU. This allows other higher priority machines running on that ECU to use that resource. This management by the controller dynamically redistributes the ECU load and maintains the functionality of the in-vehicle system.

Second Modified Example In the above embodiment, it is assumed 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 a controller, and dynamically redistributes the load in each ECU cluster independently. As a result, even if the overall scale of the in-vehicle system increases and the number of ECUs increases, dynamic load redistribution can be easily performed.

Furthermore, in the above embodiment, information regarding the virtual ECU in each ECU is synchronized between the ECUs. However, this disclosure is not limited to such embodiments. Instead of performing such synchronization all the time, it may be performed immediately before migration.

In the above embodiment, the layout configuration information regarding the virtual ECU is described in three configuration files. However, this disclosure is not limited to such embodiments. The arrangement information may be written in one configuration file, or may be written in two, four or more configuration files. Further, the arrangement information regarding the virtual ECU does not need to be written in the file. The arrangement information may be stored in a database, for example. This database may be provided for each ECU cluster, or only one database may be provided for the entire in-vehicle system. If only one database is provided 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. Furthermore, the arrangement and configuration information regarding these virtual ECUs may be collectively written as literals within the source program of the controller program. In this case, it is necessary to compile the controller program, but changing the contents of the layout configuration information itself can be done easily. Furthermore, for example, for each ECU cluster, a program may be created separately from the controller program that, when called, returns the arrangement configuration information in that ECU cluster or a pointer indicating their storage address in a certain format as a return value. In this case, there is no need to recompile the controller program itself.

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 embodiments. For example, a predetermined class may be defined in advance for virtual machine priority, initially secured resources, or a combination thereof. In this case, the priority, the initially secured resource, or a combination thereof may be specified using the class name or class identifier.

The embodiments disclosed this time should be considered to be illustrative in all respects and not restrictive. The scope of the present disclosure is not indicated by the detailed description of the disclosure, but is indicated by each claim, and includes all changes within the scope and meanings equivalent to the wording of the claims. It is intended that

42, 100, 430, 460 ECU
60, 170, 172 Physical hardware layer 62 Virtualization infrastructure layer 64 Virtual machine layer 110, 150, 220, 320, 410 1st ECU
112, 152, 224, 324, 412 2nd ECU
140, 400 On-board ECU cluster 154 Synchronization processing section 176, 422 Migration 200, 300, 450 On- board system 222, 322, 462 On-board network 230 Sensor 232 Vehicle control signal line 240, 340 Controller 242, 342 Storage section 326 Controller ECU
370 Operating 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 department

Claims (9)

1. 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,
   Each of the first information processing device and the second information processing device,
   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 infrastructure of the first information processing device and the second information processing device, and the controller is configured to operate the first information processing device. An in-vehicle system that monitors the usage status of hardware resources in the apparatus and the second information processing apparatus, and changes the configuration of the one or more virtual machines in real time according to the usage status of the hardware resources.
2. The controller is capable of communicating with the first information processing device and the second information processing device included in the information processing device cluster, and is provided independently of the first information processing device and the second information processing device. The in-vehicle system according to claim 1, comprising a controller device.
3. The in-vehicle system according to claim 1, wherein the controller includes a virtual controller executed on the virtualization infrastructure of the first information processing device.
4. The controller includes:
   a layout configuration recording unit that records layout configuration information that defines a layout configuration of the one or more virtual machines;
   The operating status of the first information processing device and the second information processing device is monitored, and the one or more virtual machines inside the information processing device cluster are monitored so that the one or more virtual machines operate stably. The in-vehicle system according to any one of claims 1 to 3, further comprising a placement control section that determines the placement of machines in real time and changes the placement if necessary.
5. The arrangement configuration information is
   Operation destination designation information that records a virtual machine to be operated in an information processing device that is a specific operation destination in the one or more virtual machines, and information that specifies the information processing device that is the specific operation destination;
   Priority information specifying a priority when allocating the hardware resources with respect to the one or more virtual machines;
   initial resource information that specifies the initial allocation of the hardware resources when starting the one or more virtual machines; or at least any two of the operating destination designation information, the priority information, and the initial resource information. The in-vehicle system according to claim 4, comprising: .
6. The arrangement configuration information is
   Operation destination designation information that records a virtual machine to be operated on an information processing device as a specific operation destination among the one or more virtual machines, and information specifying the information processing device as the specific operation destination;
   and priority information specifying a priority when allocating the hardware resources with respect to the one or more virtual machines,
   The priority includes a highest first priority and a second priority lower than the first priority,
   The placement control unit monitors the usage status of the hardware resources in the first information processing device, and in response to detecting a shortage of the hardware resources in the first information processing device, Among the virtual machines being executed in the information processing device, a virtual machine that is indicated by the operation destination specification information as being movable to the second information processing device and whose priority is the second priority is selected. The in-vehicle system according to claim 4, further comprising an operation destination control unit that selects and moves to the second information processing device.
7. The placement control unit further monitors the usage status of the hardware resources in the first information processing device and the second information processing device, and even after the virtual machine is moved by the operation destination control unit, the arrangement control unit In response to the detection of the shortage of hardware resources, among the virtual machines running on the information processing device in which the shortage of the hardware resources was detected, the priority is set to the second priority. The in-vehicle system according to claim 6, further comprising a resource reduction unit that reduces allocation of the hardware resources to a certain virtual machine.
8. The in-vehicle system according to any one of claims 1 to 7, 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 that can communicate with each other, the method comprising:
   Each of the first information processing device and the second information processing device,
   computer hardware; and a virtualization infrastructure operating on the computer hardware;
   The control method includes:
   a step in which the computer runs one or more virtual machines on the virtualization infrastructure of each of the first information processing device and the second information processing device;
   a step in which the computer monitors the usage status of hardware resources in the first information processing device and the second information processing device;
   A method for controlling an in-vehicle system, the method comprising: changing the configuration of the one or more virtual machines in real time in response to the detection of a shortage of the hardware resources in the first information processing device.
   

Images