Vehicle-mounted system and control method of vehicle-mounted system

Abstract

The vehicle-mounted system comprises an information processing device cluster, and the information processing device cluster comprises a first information processing device and a second information processing device which can communicate with each other. The first information processing device and the second information processing device respectively comprise computer hardware and a virtualization platform for executing actions on the computer hardware, and the vehicle-mounted system further comprises a controller for enabling one or more virtual machines to act in the virtualization platforms of the first information processing device and the second information processing device, the controller monitors the usage status of the computer hardware resources in the first information processing 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.

Description

Technical Field

[0001] The present disclosure relates to an in-vehicle system and a control method for the in-vehicle system. This application claims priority based on Japanese application No. 2022-138903 filed on September 1, 2023, and all the contents described in the above Japanese application are incorporated herein by reference. Background Art

[0002] Conventionally, a vehicle is equipped with a plurality of ECUs (Electronic Control Units) for controlling various parts of the vehicle. ECUs are essentially computers. Therefore, ECUs can perform interrupt processing and can respond appropriately in emergencies.

[0003] ECU was originally used for engine control. However, as vehicle equipment has become electronic, ECU is used in various places. For example, the processing of information collected by various sensors installed in the vehicle is also the responsibility of ECU. ECU is also used in determining the driving state of the vehicle, controlling the brakes, controlling electrical equipment, lane keeping systems, and inter-vehicle distance control systems.

[0004] On the other hand, the processing performed by the ECU in the vehicle has also increased beyond the increase in the number of ECUs mounted on the vehicle. Therefore, there is a technology that divides these processes into multiple tasks and executes them in multiple ECUs respectively. However, in the case of vehicle-mounted ECUs, the size of the load of each task varies greatly depending on the situation. Therefore, it is necessary to dynamically distribute the load of the ECU.

[0005] Patent document 1 discloses a solution to this problem. The technology disclosed in patent document 1 enables the ECU that executes the task to have a virtual device driver for transparently utilizing the external device. Furthermore, when the task is transferred (migrated) to another ECU, the virtual device driver is also transferred to the ECU of the transfer destination. Thus, the external device can also be transparently utilized in the ECU of the transfer destination. In addition, the migration is performed during the operation of the ECU. Such migration is called "dynamic migration". All the migrations described in this specification are dynamic migrations, and for the sake of simplicity, they are referred to as "migration".

[0006] Prior art literature

[0007] Patent Literature

[0008] Patent Document 1: Japanese Patent Application Publication No. 2009-070135

[0009] Patent Document 2: Japanese Patent Application Publication No. 2013-003946

[0010] Patent Document 3: International Publication No. 2021 / 010124 Summary of the invention

[0011] The vehicle-mounted system of the first aspect of the present disclosure includes an information processing device cluster, which includes a first information processing device and a second information processing device that can communicate with each other, wherein the first information processing device and the second information processing device respectively include computer hardware and a virtualization platform for performing actions on the computer hardware, and the vehicle-mounted system also includes a controller, which is used to enable one or more virtual machines to operate in the virtualization platforms of the first information processing device and the second information processing device, and the controller monitors the usage status of computer hardware resources in the first information processing device and the second information processing device, and changes the structure of one or more virtual machines in real time according to the usage status of the hardware resources.

[0012] The foregoing and other objects, features, aspects and advantages of the present disclosure will become more apparent from the following detailed description of the present disclosure when read in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] [ Figure 1 ] Figure 1 This is a block diagram schematically showing the structure of an ECU to which virtualization technology is applied.

[0014] [ Figure 2 ] Figure 2 It is a schematic diagram for explaining an ECU cluster.

[0015] [ Figure 3 ] Figure 3 It is a schematic diagram for explaining the migration of virtual ECUs in an ECU cluster.

[0016] [ Figure 4 ] Figure 4 This is a block diagram showing an example of the configuration of a controller that controls an ECU cluster.

[0017] [ Figure 5 ] Figure 5 This is a block diagram showing another example of the configuration of the controller that controls the ECU cluster.

[0018] [ Figure 6 ] Figure 6 This is a schematic diagram showing an example of the content of a configuration (settings) file for specifying an execution destination used in the embodiment.

[0019] [ Figure 7 ] Figure 7 This is a schematic diagram showing an example of the content of a priority configuration file used in the embodiment.

[0020] [ Figure 8 ] Figure 8 This is a schematic diagram showing an example of the content of a configuration file for initial resource designation used in the embodiment.

[0021] [ Fig. 9 ] Fig. 9 It is a schematic diagram for explaining the migration of virtual machines between different ECUs.

[0022] [ Fig.10 ] Fig.10 This is a schematic diagram for explaining the reduction of used resources (expansion of usable resources) in a single ECU.

[0023] [ Fig.11 ] Fig.11 1 is a block diagram showing the hardware configuration of the vehicle-mounted system and ECU of the present disclosure.

[0024] [ Fig.12 ] Fig.12 This is a flowchart showing a control structure of a program for resource management executed by a controller of the vehicle-mounted system according to the embodiment.

[0025] [ Fig.13 ] Fig.13 It means that the implementation is used Fig.12 A flowchart of a control structure of a computer program for a process of starting a virtual machine is shown.

[0026] [ Fig.14 ] Fig.14 It means that the implementation is used Fig.12 A flow chart showing a control structure of a computer program for a resource optimization process is shown.

[0027] [ Fig.15 ] Fig.15 It means realization Fig.14 A flow chart of the control structure of the migrated computer program is shown.

[0028] [ Fig.16 ] Fig.16 It means realization Fig.14 Flowchart of the control structure of a computer program for resource reduction processing shown. DETAILED DESCRIPTION

[0029] [Problems to be Solved by the Present Disclosure]

[0030] With the recent development of computer technology, it is possible to build a virtualization platform on one ECU and operate multiple virtual machines using independent OS (Operating System), BSW (Basic SoftWare), etc. on the virtualization platform. In other words, one or more virtual ECUs can be operated on one ECU. As a result, multiple ECUs used in the vehicle can be aggregated into a relatively small number of ECUs. However, when operating multiple virtual machines on a relatively small number of ECUs, it is also necessary to dynamically distribute the load of each ECU.

[0031] The technology disclosed in the above-mentioned patent document 1 is a load distribution at the task level of the application. When the technology disclosed in patent document 1 is applied to the ECU that operates the virtual machine, the load is distributed among multiple virtual ECUs that operate on the ECU. This method cannot reduce the load of the ECU itself that is operating the virtual machine. Such problems are not limited to ECUs, but may also occur in multiple information processing devices installed in vehicles.

[0032] The present disclosure aims to provide an in-vehicle system and a control method capable of dynamically controlling the load of an information processing device in which a virtual machine is operating.

[0033] [Effects of the present disclosure]

[0034] As described above, according to the present disclosure, it is possible to provide an in-vehicle system and a control method capable of dynamically controlling the load of an information processing device in which a virtual machine is operating.

[0035] [Description of Embodiments of the Present Disclosure]

[0036] This disclosure is summarized as follows.

[0037] (1) A vehicle-mounted system according to a first aspect of the present disclosure includes an information processing device cluster, the information processing device cluster including a first information processing device and a second information processing device that can communicate with each other, wherein the first information processing device and the second information processing device respectively include computer hardware and a virtualization platform that performs actions on the computer hardware, and the vehicle-mounted system also includes a controller, the controller is used to enable one or more virtual machines to operate in the virtualization platforms 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 structure of one or more virtual machines in real time according to the usage status of the hardware resources.

[0038] A first information processing device and a second information processing device are respectively provided in an 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 structure of the virtual machine in real time according to the usage status of the hardware resources. As a result, the load of the information processing device operated by the virtual machine can be dynamically controlled. The control of the load can be performed independently from the control of the load in other information processing device clusters, so that the dynamic control of the load of the virtual machine in the vehicle-mounted system can be easily performed.

[0039] (2) In the above (1), the controller may include a controller device that can communicate 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.

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

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

[0042] The controller is implemented as a virtual controller in the virtualization platform of the first information processing device. There is no need to independently provide hardware for executing the controller, so the cost of the vehicle-mounted device can be suppressed low and maintenance becomes easy.

[0043] (4) In any of the above (1) to (3), the controller may also include: a configuration structure recording unit, which records configuration structure information that specifies the configuration structure of one or more virtual machines; and a configuration control unit, which monitors the operating status of the first information processing device and the second information processing device, so as to determine the configuration of one or more virtual machines within the information processing device cluster in real time in a manner that enables the one or more virtual machines to operate stably, and change the configuration as needed.

[0044] The configuration structure of the virtual machine is set separately from the configuration control unit. When changing the configuration of the virtual machine, it is only necessary to change the recorded content of the configuration structure unit without changing the function of the configuration control unit. As a result, the configuration structure of the virtual machine can be easily changed.

[0045] (5) In the above (4), the configuration structure information may also include: operation destination designation information, priority information, initial resource information, or at least any two of the operation destination designation information, priority information and initial resource information, wherein the operation destination designation information records the virtual machines that should be run in the information processing device as the specific operation destination among one or more virtual machines and the information specifying the information processing device as the specific operation destination, the priority information specifies the priority when allocating hardware resources to one or more virtual machines, and the initial resource information specifies the initial allocation of hardware resources when one or more virtual machines are started.

[0046] When using the operation destination designation information, for example, it is possible to prevent a virtual machine that needs to be run in a specific information processing device from being moved to another information processing device. When using the priority information, for the vehicle system, hardware resources are preferentially allocated to more important virtual machines. As a result, the vehicle system can stably provide the specified functions. When using the initial resource information, the configuration of the virtual machine can be quickly determined when the vehicle system is started. There is no need to adjust the configuration of the virtual machine after startup, which can shorten the time required to start the vehicle system.

[0047] (6) In the above (4), the configuration structure information may also include operation destination designation information and priority information, wherein the operation destination designation information records the virtual machines that should be run in the information processing device as the specific operation destination among one or more virtual machines and the information designating the information processing device as the specific operation destination, and the priority information specifies the priority when allocating hardware resources to the one or more virtual machines, and the priority may include a highest first priority and a second priority lower than the first priority. The configuration control unit may also include an operation destination control unit, which monitors the usage status of the hardware resources in the first information processing device, and in response to detecting a shortage of hardware resources in the first information processing device, selects a virtual machine indicated by the operation destination designation information as being able to be moved to the second information processing device and having a second priority from among the virtual machines executed in the first information processing device, and moves the virtual machine to the second information processing device.

[0048] When the shortage of hardware resources is detected in the first information processing device, the virtual machine moved from the first information processing device to the second information processing device can be moved to the second information processing device and assigned the second priority. The possibility that a virtual machine important for realizing the function of the vehicle-mounted system is moved to an information processing device that cannot fully realize its function can be eliminated, and the vehicle-mounted system can stably realize the functions required of the vehicle-mounted system.

[0049] (7) In the above (6), the configuration control unit may also include a resource reduction unit that monitors the usage status of hardware resources in the first information processing device and the second information processing device, and in response to detecting a shortage of hardware resources in the vehicle system even after the virtual machine is moved by the operation destination control unit, reduces the allocation of hardware resources to the virtual machine with the second priority among the virtual machines running in the information processing device where the shortage of hardware resources is detected.

[0050] Sometimes, even after the virtual machine is moved, the shortage of hardware resources is detected, or the shortage of hardware resources cannot be eliminated because the virtual machine cannot be moved. In such a case, in the information processing device that detects the shortage of hardware resources, the allocation of hardware resources to the virtual machines with low priority is reduced. As a result, the amount of hardware resources that can be used by the virtual machines with high priority increases, and the performance of the vehicle system can be maintained.

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

[0052] Even when multiple information processing device clusters are set up, the load of the information processing devices related to the execution of the virtual machines in each information processing device cluster can be dynamically distributed independently. As a result, even if the number of virtual machines and information processing devices used in the entire vehicle-mounted device increases, the function of the vehicle-mounted system can be stably maintained.

[0053] (9) The control method of the vehicle-mounted system of the second aspect of the present disclosure is a control method of the vehicle-mounted system including a cluster of information processing devices, wherein the cluster of information processing devices includes a first information processing device and a second information processing device that can communicate with each other, wherein the first information processing device and the second information processing device respectively include computer hardware and a virtualization platform that performs actions on the computer hardware, and the control method includes the following steps: a computer enables one or more virtual machines to run in each virtualization platform of the first information processing device and the second information processing device; the computer monitors the usage status of hardware resources in the first information processing device and the second information processing device; and in response to detecting a shortage of hardware resources in the first information processing device, the structure of one or more virtual machines is changed in real time.

[0054] A first information processing device and a second information processing device are respectively provided in an 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 of the information processing device operated by the virtual machine can be dynamically controlled. The control of the load can be performed independently from the control of the load in other information processing device clusters, so that the dynamic control of the load of the virtual machine in the vehicle-mounted system can be easily performed.

[0055] [Details of the embodiments of the present disclosure]

[0056] Hereinafter, a specific example of a vehicle-mounted system and a control method thereof according to an embodiment of the present disclosure will be described with reference to the accompanying drawings. In the following description and the accompanying drawings, the same reference numbers are marked on the same components. Therefore, their detailed descriptions are not repeated. In addition, the present disclosure is not limited to these examples, and is represented by the claims, which are intended to include all changes within the meaning and scope equivalent to the claims. In addition, one or more arbitrary features of the following embodiments may also be combined.

[0057] First embodiment

[0058] 1. Structure

[0059] A. ECU

[0060] Figure 1 The schematic structure of the ECU 42 according to the first embodiment of the present disclosure is shown. Figure 1 ECU 42 includes a physical hardware layer 60 including computer hardware, a virtualization platform 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 platform layer 62. The virtualization platform layer 62 uses hardware resources such as the physical hardware layer 60.

[0061] The virtual ECUs all perform the same tasks as the previous ECUs. These virtual ECUs all operate in a virtual operating environment that is the same as the previous operating environment and is provided by the virtualization platform layer 62. Therefore, the OS and applications executed by the virtual ECUs are the same as the OS and applications executed by the previous individual ECUs.

[0062] B. ECU Cluster

[0063] like Figure 1 As shown, multiple virtual ECUs can be operated by one ECU. However, when multiple virtual ECUs are operated on each ECU, the load on a specific ECU may be too large. It is necessary to avoid such a situation.

[0064] In order to avoid such problems, the concept of ECU cluster is introduced in this embodiment. An ECU cluster refers to a group composed of multiple ECUs that respectively activate one or more virtual ECUs. When migrating (moving) virtual ECUs, the ECU cluster specifies the range of the migration destination as described later. That is, a virtual ECU that operates in an ECU within a certain ECU cluster can be migrated to other ECUs within the same ECU cluster, but not to ECUs in other ECU clusters. A controller is set in the ECU cluster constructed in this way. The controller is used to balance the load of each ECU in the cluster or reduce the load in each ECU by monitoring the resource usage of each ECU in the ECU cluster. By setting up an ECU cluster, it is possible to reduce the number of ECUs and virtual ECUs managed by one controller, making it easier to manage and enabling the necessary processing to be performed quickly.

[0065] Alternatively, you can consider not using ECU clusters and making each ECU large-scale and high-performance to avoid excessive load. Figure 2 The example based on such an idea is shown in the upper part of ECU100. In this example, a plurality of virtual machines are operated in ECU100. Figure 2 The following paragraph shows an example of this idea based on ECU clustering. Figure 2 In the form shown in the lower part of the figure, a plurality of ECUs (e.g., the first ECU 110 and the second ECU 112) with smaller scale and lower performance than the ECU 100 shown in the upper part form an ECU cluster. In the first ECU 110 and the second ECU 112, a plurality of virtual ECUs operate separately. The performance of the ECU here is inferior to that of the ECU 100, but by adopting Figure 2 The ECU cluster shown in the lower section can provide Figure 2 Same level of computing resources as the previous paragraph.

[0066] However, in actual vehicles, it is preferred to use Figure 2 The reason is as follows. As mentioned above, according to Figure 1 In the structure of the upper part, when the resources of ECU 100 are insufficient, the virtual ECU cannot be migrated to other ECUs. Figure 2In the structure shown in the lower section of , it is possible to migrate virtual ECUs between ECUs belonging to the same ECU cluster. In addition, when using products of the same specification 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 the increase in cost caused by using ECUs with excess performance. In addition, it has the following advantages: the supply unit price of ECUs is reduced due to mass production costs, resulting in a reduction in the manufacturing cost of the vehicle.

[0067] Figure 3 illustrate Figure 2 The migration in the structure of the next paragraph. Figure 3 The vehicle-mounted 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). Figure 3 As shown on the left end of FIG. 1 , when the resources of the first ECU 150 are insufficient, if the resources of the second ECU 152 are sufficient, one of the virtual ECUs operating in the first ECU 150 is migrated to the second ECU 152 176. By migrating the virtual ECUs, the resources of the first ECU 150 are sufficient, and the stable operation of the 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 ECUs due to insufficient resources.

[0068] In addition, in order to perform such a migration, the state of the virtual ECU (the contents of the memory, virtual registers, etc.) also needs to be transferred from the first ECU 150 to the second ECU 152. In this embodiment, these state information are not transferred at the time of migration, but by setting a synchronization processing unit 154, the storage content of the physical hardware layer 170 of the second ECU 152 is always synchronized with the storage content of the physical hardware layer 172 of the second ECU 152. As a result, the state information before the migration is also stored in the physical storage when the migration occurs, so the virtual ECU can continue to operate. In addition, as described later, in the virtual ECU, since the ECU of the operation destination is specified, or the resource allocation priority is set higher, there are also virtual ECUs that do not migrate. For such virtual ECUs, this synchronization processing is not required.

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

[0070] Figure 4 This shows the first example of the controller configuration. Figure 4The vehicle-mounted system 200 includes a first ECU 220 and a second ECU 224 that can communicate with each other through a vehicle-mounted network 222. The first ECU 220 is connected to a sensor 230, for example. The second ECU 224 is connected to a device different from 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 structure of the virtual ECU in the vehicle-mounted system 200. The controller 240 acts as a virtual machine like other virtual ECUs. That is, the controller 240 can be called a virtual controller.

[0071] The controller 240 has certain restrictions on the dynamic control of the structure of the virtual ECU. For example, the first ECU 220 is connected to the sensor 230, etc. Therefore, the virtual ECU that is operating the task of processing the information from these sensors 230, etc. must be resident in the first ECU 220 and cannot be migrated to the second ECU 224. Similarly, the second ECU 224 is connected to the body control signal line 232, etc. Therefore, the task of performing body control must function in the virtual ECU operating on the second ECU 224 and cannot be migrated to the first ECU 220.

[0072] The controller 240 has a storage unit 242 for storing such constraints related to the configuration of the virtual ECU and conditions related to how the virtual ECU is configured in the first ECU 220 and the second ECU 224 when the vehicle-mounted system 200 is started. The storage unit 242 holds these conditions in the form of configuration files, and reads these conditions when the controller 240 is started. Hereinafter, configuration is referred to as "configuration", and configuration files are referred to as "configuration files". Examples of the content of the configuration files are described later.

[0073] Figure 5 This shows another example of the controller configuration. Figure 5 The vehicle system 300 includes: a vehicle network 322; a first ECU 320 and a second ECU 324, which can communicate with each other via the vehicle network 322 and can host one or more virtual ECUs respectively; and a controller ECU 326, which can communicate with the vehicle network 322 and the second ECU 324 via the vehicle network 322 and is a controller device independently set up with them. In this example, the controller ECU 326 includes Figure 4The storage unit 342 is the same as the storage unit 242 shown in the figure. In the controller ECU 326, the controller 340 realized by the program operates. The 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 in the same manner as before.

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

[0075] Reference Figure 6 , the operation destination designation configuration 370 lists the ECUs that each virtual ECU should run. For example, Figure 4 In the case of the vehicle-mounted system 200, 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. Regarding virtual machines C and D, it is shown that there is no such ECU designation. Both virtual machines C and D can operate in either the first ECU 220 or the second ECU 224, and therefore can be migrated.

[0076] In this example, the information of "no designation" is described for virtual machine C and virtual machine D in the operation destination designation configuration 370, but the present disclosure is not limited to this form. For example, virtual ECUs not listed in the operation destination designation configuration 370 can also be designated as "no designation" by agreement as a default. However, in this case, it is necessary to be able to grasp all virtual ECUs to be started in some form. For example, a configuration file that lists the identifiers of all virtual ECUs can also be set separately.

[0077] The designation of an ECU can be performed by the name, identifier or address of the ECU. Alternatively, a prescribed sign or number may be associated with each ECU and the ECU may be designated by the sign or number. A vector having elements equal to the number of ECUs may be prepared and each element may be associated with an ECU. For an ECU capable of running a virtual ECU, the value of the corresponding element may be set to, for example, "0", and the value of the element corresponding to an ECU that cannot run may be set to, for example, "1" and designated by the vector. Alternatively, the arrangement of the elements of the vector may be regarded as a binary number and designated by the value. In this case, an octal number representation or a hexadecimal number representation may be used.

[0078] By using the execution destination designation configuration 370 in this way, the ECU at the execution destination of each virtual machine can be appropriately controlled.

[0079] Figure 7 An example of the content of the priority configuration 372 is shown. Figure 7 , the priority of each virtual ECU is stored in the priority configuration 372. In this embodiment, there are three levels of priority: high, medium, and low. In the case of an in-vehicle system, among the functions implemented by the virtual ECU, there are functions with 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 preferred if available but are not necessary for the control of the vehicle. For example, functions such as driving, turning, and stopping are related to the original functions of the vehicle and require high reliability. Among the additional functions such as the control of electric windows and infotainment, functions with relatively high priorities are preferred functions for the vehicle to have, but do not require such high reliability. Moreover, among the functions called so-called infotainment functions, functions with relatively low priorities cannot be said to be the original functions of the vehicle and are not necessary.

[0080] As described above, for virtual ECUs that implement functions that require high reliability, resources need to be allocated preferentially. On the other hand, in the case of functions that are not necessary for vehicle control, resource allocation priority is low. Each virtual ECU corresponds to these functions. Therefore, in the priority configuration 372, each virtual ECU is described with its priority.

[0081] In this example, the priority is 3 levels. However, the present disclosure is not limited to such an embodiment. The priority may be 2 levels or may be 4 or more levels.

[0082] Figure 8 This is an example of the content of the initial resource assignment configuration 374. When the vehicle-mounted system is started, each virtual ECU needs to be started. The configuration of the virtual ECU at the time of startup is preferably optimized according to the above-mentioned constraints. The initial resource assignment configuration 374 describes the conditions required for this. That is, when the vehicle-mounted system is started, the initial allocation of resources to each virtual ECU is performed according to the description of the initial resource assignment configuration 374.

[0083] Reference Figure 8 For example, in this example, in the initial resource designation configuration 374, the physical resources (CPU (Central Processing Unit) core number, memory size, etc.) to be allocated when each virtual ECU is started are described for each virtual ECU. As described later, the controller refers to the content of the initial resource designation configuration 374 to determine the optimal virtual ECU configuration. In addition, after the vehicle system is started, the configuration of the virtual ECU changes dynamically according to the resource usage status of each ECU. Therefore, in this embodiment, Figure 8The initial resource designation configuration 374 shown is only used to determine the configuration of the virtual ECU when the vehicle-mounted system is started. Of course, the initial resource designation configuration 374 can also be used to dynamically change the resource configuration while maintaining the initial configuration as much as possible.

[0084] In addition, in this embodiment, the controller performs two processes, namely, migration and resource reduction, on the virtual ECU after the vehicle-mounted system is activated. This will be described below.

[0085] First, migration is explained. Migration refers to transferring a virtual ECU operating in a certain ECU to another ECU in the same ECU cluster. At this time, the operations of other virtual ECUs in the ECU cluster do not stop, but the migrated virtual ECU is stopped instantly (a few milliseconds or so). Therefore, virtual ECUs that require high reliability should not be migrated. In addition, virtual ECUs that specify the destination ECU cannot be migrated. Therefore, the following restrictions are set in this embodiment. By setting the following restrictions, virtual ECUs that are less important and do not depend on the device can be actively migrated. As a result, the load of each ECU can be dispersed, and stable operation of the virtual ECU can be achieved in each ECU.

[0086] Virtual ECUs with priority "high" cannot be migrated

[0087] Virtual ECUs with a priority of "Medium" ... can be migrated

[0088] Virtual ECUs with a "low" priority... can be migrated

[0089] There is a virtual ECU specified as the operation destination...cannot be migrated

[0090] Virtual ECU without operation destination specified...can be migrated

[0091] Reference Fig. 9 , the vehicle-mounted ECU cluster 400 includes a first ECU 410 and a second ECU 412. Virtual machine A runs in the first ECU 410. Its resource occupancy rate is 30%. In the first ECU 410, other virtual ECUs do not run. Therefore, the idle resources are 70%. In addition, "resource occupancy rate" is a concept that combines the CPU occupancy rate and the memory occupancy rate. How to calculate the resource occupancy rate varies according to the designer's ideas.

[0092] On the other hand, virtual machine B and virtual machine C are running in virtual machine B420, and their resource occupancy rates are set to 40% and 55% respectively. The idle resources are 5%. The controller is programmed to determine that the ECU's resources are tight when the amount of idle resources of the ECU is below a specified threshold (for example, 15%). Fig. 9In the case of the state shown, it is determined that the resources in the second ECU 412 are insufficient.

[0093] exist Fig. 9 In the example shown, for example, it is assumed that both virtual machine B and virtual machine C are allowed to migrate. Then, in this case, the controller decides the virtual ECU to migrate so that the allocation of resources after migration is as balanced as possible. That is, Fig. 9 In the example shown, virtual machine B 420 migrates 422 from second ECU 412 to first ECU 410. As a result, the free resources of first ECU 410 decrease to 30%, but the resources are not tight, and the free resources in second ECU 412 increase to 45%, and the operation of virtual machine C can be stably maintained.

[0094] Assume that only Fig. 9 When the migration 422 shown cannot avoid the resource shortage situation of the first ECU 410 or the second ECU 412 , the controller executes a process of reducing the resource allocation to the virtual ECU (resource reduction process).

[0095] The resource reduction process is described below. In addition, the resource reduction process affects the performance of the virtual ECU to be targeted. Therefore, the following restrictions are set on the allocation and reduction of resources.

[0096] Virtual ECUs with a "high" priority can use resources without restriction.

[0097] Virtual ECUs with a "medium" priority can use resources without restriction.

[0098] Virtual ECUs with a "low" priority can use resources as long as they are available. However, when resources are scarce, resources will be reduced.

[0099] Fig.10 This section provides an overview of resource allocation processing. Fig.10 For example, in ECU 430, the resource occupancy rate of virtual machine A with high priority is as high as 60%, but the idle resource 440 is 5%, which is below the threshold, and resource shortage is detected. Virtual machine A can also request resources. At this time, there may be a situation where other ECUs do not have enough idle resources and virtual machine B with low priority cannot be migrated to other ECUs. In such a case, in this embodiment, Fig.10 As shown on the right side of , by reducing the resources allocated to the low-priority virtual machine B, the amount of idle resources 442 is made greater than a threshold value (eg, 20%), thereby attempting to eliminate resource shortage.

[0100] As a method of reducing the allocated resources, in the case of CPU, the number of allocated cores can be reduced. In the case of memory, methods such as so-called memory ballooning, memory swapping, and memory compression can be mentioned.

[0101] C. Hardware and Software

[0102] Fig.11 The hardware structure of the vehicle-mounted system 450 realizing the present embodiment is shown in the form of a block diagram. Fig.11 The vehicle system 450 includes a vehicle network 462 and a first ECU cluster 452, a second ECU cluster 454, and a third ECU cluster 456 connected to the vehicle network 462. In these clusters, the specific structures (the number of ECUs and the number of virtual machines running, etc.) may be different from each other, but the basic structure is the same. Therefore, the structure and operation of the first ECU cluster 452 will be described below.

[0103] The first ECU cluster 452 includes an ECU 460 connected to the vehicle network 462 and one or more ECUs 466 connected to the vehicle network 462. In this embodiment, the ECU 460 and each ECU of the plurality of ECUs 466 are of the same specification. In addition, the ECU 460 can be used as an ECU providing a virtual platform or as a controller ECU. In the following description, the ECU 460 is set as a controller ECU, and the virtual ECU is set to be operated in the plurality of ECUs 466.

[0104] ECU 460 is essentially a computer, including CPU 482, main storage device 484, auxiliary storage device 486, input / output I / F (Interface) 488, vehicle network communication unit 490, and bus 480 that connects all of these to each other so that they can communicate. Signals from various devices 464 such as cameras and CAN (Controller Area Network) signals are input to input / output I / F 488. Vehicle network communication unit 490 is an I / F for vehicle network 462 for ECU 460. ECU 460 can communicate with all other ECUs belonging to multiple ECUs 466 via vehicle network communication unit 490 and vehicle network 462.

[0105] The program executed by CPU482 is stored in the auxiliary storage device 486. When executing the program, CPU482 reads the program from the specified address of the auxiliary storage device 486. CPU482 loads the program into the main storage device 484, reads the command from the specified address and executes it. CPU482 decodes the read command. As a result of the decoding, CPU482 reads data from the address specified by the command, performs the operation specified by the decoding result, and stores the result in the address specified by the command. CPU482 has a program counter (not shown), and updates its content according to the execution result of the command. CPU482 reads a new command from the address of the main storage device 484 specified by the updated program counter and executes it. CPU482 implements the function defined by the program by performing such processing.

[0106] In addition, in this embodiment, it is assumed that the CPU 482 has multiple cores and can also execute speculative instructions. As a result, various processes can be executed at high speed.

[0107] The entity of the virtual ECU is a file installed in the auxiliary storage device 486. Similarly, the CPU 482 loads the virtualization program installed in the auxiliary storage device 486 into the main storage device 484 and executes it. The virtualization program reads the file of the virtual ECU and simulates the CPU according to its content, thereby realizing the virtual ECU. Specifically, as the virtualization program, it is preferred to use a type of program called a hypervisor that directly provides access to the hardware resources of the computer without going through the host OS. Of course, it is not limited to the hypervisor, and a virtualization program that operates on the host OS can also be used.

[0108] The following describes the control structure of the program that realizes the functions of the controller in this embodiment. Figure 5 As shown, the controller is an application that operates on the host CPU rather than in a virtualized environment in the controller ECU 326 which is a dedicated computer. The program is started by starting the controller ECU 326 and loading the controller program (hereinafter referred to as the "controller program") into the memory within the startup sequence. The program repeatedly executes the processing described below, and detects and executes certain processing requests related to the maintenance of the virtual machine (requests for migration and resource reduction, etc.) in real time. The real-time execution mentioned here refers to the so-called real-time processing in information processing technology. Real-time processing is a concept contrasted with batch processing, and refers to the situation where certain processing requests are processed immediately when they are generated.

[0109] Reference Fig.12 , the controller program secures and initializes the storage area and various control variables immediately after startup, and then reads the virtual ECU's operation destination designation configuration 370 ( Figure 6 ) step 500, read the priority configuration 372 of the virtual ECU ( Figure 7 ) step 502, and read the initial resource designation configuration 374 of the virtual ECU ( Figure 8 ) step 504. The controller program saves the information read from these configuration files into various variables within the program.

[0110] The program further includes a step 506 of starting all virtual ECUs after step 504. In order to start all virtual ECUs, the information read in the above steps 500, 502 and 504 is required.

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

[0112] The program further includes a step 510 of terminating all virtual ECUs and terminating the execution of the controller program after the instructing to stop the in-vehicle system and the processing of step 508 is completed.

[0113] Reference Fig.13 , step 506 of starting the virtual ECU includes: step 530, extracting all virtual ECU configuration modes specified by the operation destination specified configuration 370; and step 532, locking the configuration mode with the smallest number of configurations of high priority devices in each single ECU from the configuration modes extracted in step 530.

[0114] The program also includes step 534, which calculates the resource utilization rate in each ECU for each configuration mode remaining in step 532 based on the content of the initial resource designation configuration 374. The resource utilization rate mentioned here is a concept that combines the CPU utilization rate and the memory utilization rate as described above. The program also includes step 536, which branches the control process according to whether there is a configuration mode in which both the CPU utilization rate and the memory utilization rate calculated in step 534 are below the specified values. The specified values ​​mentioned here refer to both the first specified value as the specified value of the memory utilization rate and the second specified value as the specified value of the memory utilization rate. These two specified values ​​do not need to be the same. In addition, multiple specified values ​​appear in the following description, but these values ​​can be the same or different.

[0115] The program also includes: step 538, when the determination in step 536 is negative, the control process is branched according to whether there is a configuration mode in which the CPU usage rate is less than the third specified value; and step 540, when the determination in step 538 is negative, the control process is branched according to whether there is a configuration mode in which the memory usage rate is less than the 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 have to be the same. For example, the third specified value may also be less than the first specified value. Similarly, in this embodiment, the fourth specified value is the same as the second specified value, but they do not need to be the same. For example, the fourth specified value may also be less than the second specified value.

[0116] The program includes: step 542, when the determination in step 536, step 538 or step 540 is affirmative, locking the configuration mode to the configuration mode that meets the conditions specified in these steps; and step 544, selecting the configuration mode with the smallest difference in CPU usage between all ECUs from the configuration modes remaining in step 542. The program also includes step 546, according to the configuration mode selected in step 544, allocating virtual ECUs to each ECU, starting all virtual ECUs and ending step 506.

[0117] If the determination in step 540 is negative, processing is performed in step 548 in the case where an appropriate configuration related to the virtual ECU is not found. In step 548, for example, it is considered to change the configuration file so that the virtual ECU with a low priority is not started and step 506 is executed again. Alternatively, for the virtual ECU with a low priority, the resources allocated can be uniformly reduced and step 506 can be executed again. Depending on the situation, it can also be displayed that the virtual ECU cannot be started and the user's instruction is accepted.

[0118] In addition, as the "difference" in the "configuration mode with the smallest difference in CPU usage" in step 544, any one of the range (the difference between the maximum and minimum values), the average deviation, or the variance of the CPU usage in each of these configuration modes after the CPU usage in each configuration mode is calculated in all ECUs may be used.

[0119] Reference Fig.14 , Fig.12 Step 508 includes: step 600, monitoring the resource usage of each ECU; and step 602, branching the control flow according to the monitoring result in step 600 and whether there is an ECU with insufficient resources. The determination in step 602 is positive when, for example, the CPU usage in a certain ECU exceeds a specified value or the memory usage exceeds a specified value. If the determination in step 602 is negative, the control returns to step 600 and the resource monitoring is performed again.

[0120] The program further includes step 604, in which, when the determination in step 602 is affirmative, any one of the virtual ECUs operating in the ECU determined to be resource-constrained is migrated to another ECU. Fig.15 This will be described later.

[0121] The program also includes step 606, which branches the control flow according to whether the resource shortage is eliminated after step 604. The determination in step 606 is made according to whether the resource utilization rate in all ECUs of the vehicle system is below a specified value. If the determination in step 606 is affirmative, the control returns to step 600 and the resource monitoring is restarted. The program also includes step 608, which is executed in response to the determination in step 606 being negative, to reduce the resources of the low-priority device. Thereafter, the control returns to step 600. In the following description, reference is made to Fig.16 The content of step 608 is described below. Thus, in this embodiment, the controller always monitors whether resource tension occurs by comparing various indicators with the specified values. If the result of the comparison between the indicators and the specified values ​​indicates that resource tension occurs, the controller determines that the tension needs to be eliminated and immediately executes the processing for this.

[0122] Reference Fig.15 The control structure of the program for executing the migration in step 604 is described. Step 604 includes step 650, which branches the control flow according to whether there is a medium / low priority virtual ECU running in the ECU with limited resources. If the determination in step 650 is negative, the execution of step 604 ends.

[0123] Step 604 also includes: step 652, when the determination in step 650 is affirmative, extracting the migratable virtual ECU; and step 654, for the virtual ECU extracted in step 652, extracting all executable migration modes, and calculating the prediction of resource usage after migration for each mode.

[0124] Step 604 further includes: step 656, branching the control flow according to whether there is a combination in which both the CPU usage rate and the memory usage rate are below the prescribed value as a result of the processing in step 654; and step 658, when the determination in step 656 is affirmative, executing the migration of the target virtual ECU to realize the combination found in step 656, and ending step 604. In addition, the prescribed value of the CPU usage rate in step 656 is set to the fifth prescribed value, and the prescribed value of the memory usage rate is set to the sixth prescribed value.

[0125] Step 604 also includes: step 660, when the judgment in step 656 is negative, the control process is branched according to whether there is a combination in which the CPU usage is below the seventh specified value; and step 662, when the judgment in step 660 is affirmative, the migration of the object's virtual ECU is executed to realize the combination found in step 660, and step 604 is ended.

[0126] Step 604 further includes: step 664, when the determination in step 660 is negative, branching the control flow according to whether there is a combination in which the memory usage rate is less than the eighth predetermined value; and step 666, when the determination in step 664 is positive, executing the migration of the target virtual ECU to realize the combination found in step 664, and ending step 604. If the determination in step 664 is negative, the migration is not performed and step 604 ends.

[0127] In steps 658 and 662 or step 664, when there are multiple possible combinations, use Fig.13 The combination can be selected based on the same criteria as step 544.

[0128] Reference Fig.16 , Fig.14 Step 608 includes: step 700, extracting all low-priority devices running in the ECU (target ECU) where resource shortage is detected; step 702, branching the control flow according to whether the CPU usage rate of the target ECU is above the ninth specified value; and step 704, when the determination in step 702 is affirmative, reducing the CPU usage of all low-priority devices running in the target ECU by a certain amount. When the determination in step 702 is negative, control enters step 706.

[0129] Step 608 further includes: step 706, after step 704, branching the control flow according to whether the memory usage rate in the target ECU is greater than the tenth predetermined value; and step 708, when the determination in step 706 is affirmative, reducing the memory usage of all low-priority devices in the target ECU by a certain proportion (or a certain amount) and terminating the execution of step 608. When the determination in step 706 is negative, the execution of step 608 is terminated.

[0130] 2. Action

[0131] The first ECU cluster 452 having the above structure ( Fig.11 ) proceed as follows.

[0132] A. Startup

[0133] Reference Fig.11When the power of the vehicle-mounted system 450 is turned on, the ECU 460 of the first ECU cluster 452 and the plurality of ECUs 466 are activated. In each of the plurality of ECUs 466, the hypervisor is activated and the activation instruction of the virtual ECU is awaited.

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

[0135] Reference Fig.12 ECU 460 reads out the operation destination designation configuration 370 , the priority configuration 372 , and the initial resource designation configuration 374 from the auxiliary storage device 486 (steps 500 , 502 , and 504 ), and substitutes each designated value into a predetermined variable of the program.

[0136] Reference Fig.13 ECU460 calculates the resource usage rate for each possible configuration mode of the virtual ECU by executing steps 530, 532 and 534. Furthermore, in step 536, step 538 or step 540, if there is a configuration mode of the virtual ECU that meets the conditions, the configuration mode of the virtual ECU is locked to the configuration mode in step 542. Furthermore, in step 544, ECU460 calculates the CPU usage rate in each ECU used for the virtual ECU in the first ECU cluster 452 for each remaining configuration mode. And, ECU460 selects the configuration mode with the least difference in CPU usage rate in each ECU for each configuration mode. In step 546, ECU460 assigns each virtual ECU to each ECU according to the selected configuration mode and starts it, ending the processing of step 506.

[0137] B. Monitoring and resource adjustment

[0138] return Fig.12 , ECU 460 starts the resource optimization process in step 508. Fig.14 ECU 460 monitors resources in each ECU. Specifically, ECU 460 calculates CPU usage and memory usage in each ECU.

[0139] In step 602, ECU 460 determines whether there is an ECU with insufficient resources. If there is no such ECU, control returns to step 600 and ECU 460 restarts resource monitoring. If there is an ECU with insufficient resources, ECU 460 executes in step 604. Fig.15 Migration process shown.

[0140] Reference Fig.15In the migration process of step 604, ECU 460 selects Fig.14 In step 602, a low-priority device that can be migrated and is running in an ECU (target ECU) with limited resources is detected. In step 654, ECU460 also extracts all migration modes that can be executed for the medium / low priority devices extracted in step 652. ECU460 further similarly calculates the resource usage rate after migration for each extracted migration mode in step 654. Based on the resource usage rate prediction, executable migration is performed through steps 656, 658, 660, 662, 664 and 666. In the case where the resource shortage cannot be eliminated by the resource usage rate prediction even if migration is performed, the judgments in steps 656, 660 and 664 are all negative, and migration is not performed.

[0141] Refer again Fig.14 If the result of executing step 604 is that the resource tension is eliminated, the determination of step 606 is affirmative, and the resource optimization process ends. If the resource tension is not eliminated, step 608 is executed.

[0142] Reference Fig.16 In step 608, if the CPU usage rate of the ECU in which resource shortage is detected is above the ninth prescribed value (the determination in step 702 is affirmative), the CPU usage of all low-priority devices running on the ECU is uniformly reduced (step 704). Furthermore, if the memory usage in the ECU is above the tenth prescribed value (the determination in step 706 is affirmative), the memory usage of all low-priority devices running on the ECU is reduced.

[0143] If the determination in step 702 is negative, resource reduction processing 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 device is reduced, but the memory usage is not reduced.

[0144] As described above, according to the present embodiment, an ECU cluster is composed of a plurality of ECUs, and a controller manages virtual ECUs executed in each ECU. In this management, when a resource shortage occurs in an ECU, the controller migrates the virtual ECU from the ECU to another ECU, thereby eliminating the resource shortage in the ECU. When the resource shortage is not eliminated even after migration, the controller reduces the resources of the low-priority virtual ECU running in the ECU. As a result, other devices with higher priority running in the ECU can use the resources. By performing such management by the controller, the load of the ECU is dynamically redistributed, and the function of the vehicle-mounted system can be maintained.

[0145] Second Modification

[0146] In the above-mentioned embodiment, it is assumed that there is one ECU cluster in the vehicle-mounted system. However, the present disclosure is not limited to such an embodiment. The vehicle-mounted system may also 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 vehicle-mounted system becomes larger and the number of ECUs increases, dynamic redistribution of the load can be easily performed.

[0147] In addition, in the above-mentioned embodiment, the information related to the virtual ECU in each ECU is synchronized between the ECUs. However, the present disclosure is not limited to such an embodiment. Such synchronization may not be performed all the time, but may be performed just before the migration.

[0148] In the above-mentioned embodiment, the configuration structure information related to the virtual ECU is described in three configuration files. However, the present disclosure is not limited to such an embodiment. The configuration structure information can be described in one configuration file or in two or more configuration files. In addition, the configuration structure information related to the virtual ECU does not need to be described in a file. The configuration structure information can be stored in a database, for example. The database can be set for each ECU cluster, or only one can be set for the entire vehicle system. In the case where only one database is set for the entire vehicle system, it is necessary to assign an identifier to the ECU cluster and set a field for the identifier in each record of the database. In addition, within the source program of the controller program, the configuration structure information related to these virtual ECUs can also be uniformly described as text. In this case, the controller program needs to be compiled, but the content of the configuration structure information can be easily changed. In addition, for example, a program can be made separately from the controller program for each ECU cluster, and the program returns the configuration structure information in the ECU cluster or the pointer representing their storage address as a return value in a certain format when called. In this case, recompilation of the controller program itself is not required.

[0149] In the above-mentioned embodiment, the configuration structure information is described in the configuration file according to the name or identifier of each specific virtual ECU. However, the present disclosure is not limited to such an embodiment. For example, it is also possible to predefine a specified category for the priority, initial guaranteed resources, or a combination thereof of a virtual machine. In this case, the priority, initial guaranteed resources, or a combination thereof can be specified by its category name or category identifier.

[0150] The embodiments disclosed herein are illustrative in all aspects and should not be construed as restrictive. The scope of the present disclosure is not indicated by the detailed description of the disclosure but by each claim of the claims, and is intended to include all modifications within the meaning and scope equivalent to the words and phrases of the claims.

[0151] Description of Reference Numerals

[0152] 42, 100, 430, 460 ECU

[0153] 60, 170, 172 Physical hardware layer

[0154] 62 Virtualization Platform Layer

[0155] 64 Virtual Machine Layer

[0156] 110, 150, 220, 320, 410 First ECU

[0157] 112, 152, 224, 324, 412 Second ECU

[0158] 140, 400 vehicle ECU cluster

[0159] 154 Synchronous Processing Unit

[0160] 176, 422 Migration

[0161] 200, 300, 450 Vehicle System

[0162] 222, 322, 462 In-vehicle network

[0163] 230 Sensors

[0164] 232 Body control signal line

[0165] 240, 340 controller

[0166] 242, 342 Storage

[0167] 326 Controller ECU

[0168] 370 Run destination specified configuration

[0169] 372 Priority Configuration

[0170] 374 Initial Resource Assignment Configuration

[0171] 420 Virtual Machine B

[0172] 440, 442 Idle Resources

[0173] 452 First ECU Cluster

[0174] 454 Second ECU Cluster

[0175] 456 Third ECU Cluster

[0176] 464 Various devices

[0177] 466 Multiple ECUs

[0178] 480 bus

[0179] 482 CPU

[0180] 484 Main storage device

[0181] 486 Auxiliary storage device

[0182] 488 Input and Output I / F

[0183] 490 In-vehicle Network Communication Department

Claims

1. A vehicle-mounted system, comprising an information processing device cluster, wherein the information processing device cluster comprises a first information processing device and a second information processing device capable of communicating with each other, wherein: The first information processing device and the second information processing device respectively include: computer hardware; and a virtualization platform that performs actions on said computer hardware, The vehicle-mounted system also includes a controller, which is used to activate one or more virtual machines in the virtualization platform 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 structure of the one or more virtual machines in real time according to the usage status of the hardware resources.

2. The vehicle-mounted system according to claim 1, wherein: The controller includes a controller device that can communicate 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.

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

4. The vehicle-mounted system according to any one of claims 1 to 3, wherein: The controller comprises: A configuration structure recording unit, recording configuration structure information, wherein the configuration structure information specifies the configuration structure of the one or more virtual machines; and The configuration control unit monitors the operating status of the first information processing device and the second information processing device to determine the configuration of the one or more virtual machines within the information processing device cluster in real time in a manner that enables the one or more virtual machines to operate stably, and changes it as needed.

5. The vehicle-mounted system according to claim 4, wherein: The configuration structure information includes: The operation destination designation information records a virtual machine that should be executed in the information processing device as a specific operation destination among the one or more virtual machines and information designating the information processing device as the specific operation destination; Priority information, specifying a priority for allocating the hardware resources to the one or more virtual machines; Initial resource information, specifying an initial allocation of the hardware resources when the one or more virtual machines are started; or At least any two of the execution destination designation information, the priority information, and the initial resource information.

6. The vehicle-mounted system according to claim 4, wherein: The configuration structure information includes: execution destination designation information recording a virtual machine that should be executed in an information processing device that is a specific execution destination among the one or more virtual machines and information designating the information processing device that is the specific execution destination; and priority information, for the one or more virtual machines, specifying a priority when allocating the hardware resources, The priorities include a first priority which is the highest and a second priority which is lower than the first priority. The configuration control unit includes an operation destination control unit, which 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, selects a virtual machine from among the virtual machines executed in the first information processing device that is indicated by the operation destination designation information as being able to move to the second information processing device and having a priority of the second priority, and moves the virtual machine to the second information processing device.

7. The vehicle-mounted system according to claim 6, wherein: The configuration control unit also includes a resource reduction unit, which 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 situation where the shortage of hardware resources is detected in the vehicle system even after the virtual machine is moved by the operation destination control unit, reduces the allocation of the hardware resources to the virtual machine with the second priority in the virtual machine running in the information processing device where the shortage of hardware resources is detected.

8. The vehicle-mounted system according to any one of claims 1 to 7, wherein: The in-vehicle system includes a plurality of information processing device clusters.

9. A control method for an in-vehicle system, the in-vehicle system comprising an information processing device cluster, the information processing device cluster comprising a first information processing device and a second information processing device capable of communicating with each other, wherein: The first information processing device and the second information processing device respectively include: Computer hardware: and a virtualization platform that performs actions on said computer hardware, The control method comprises the following steps: The computer enables one or more virtual machines to run in each of the virtualization platforms of the first information processing device and the second information processing device; The computer monitors the usage status of the hardware resources in the first information processing device and the second information processing device; and In response to detecting a shortage of the hardware resources in the first information processing device, the structure of the one or more virtual machines is changed in real time.

Images