Pool Management for In-Vehicle Device / Application Startup

Abstract

A method, computer program product, and system for pre-pooling virtual machine components prior to application launch. The method includes reading a virtual machine pool manifest by a virtual machine pool manager. The virtual machine pool manifest includes an initial number of virtual machines to launch, a number of virtual machines to allocate resources to, and an amount of resources to allocate based on virtual machine resource definitions. The method further includes launching a plurality of base virtual machines into the virtual machine pool based on the initial number provided by the virtual machine pool manifest. The base virtual machines lack initial application allocations. The method further includes allocating initial resources to some of the base virtual machines based on the virtual machine resource definitions in the virtual machine pool manifest. The method includes loading a core program package into some of the base virtual machines.

Description

Technical Field

[0001] The present disclosure relates to the application startup speed in an in-vehicle device, and more particularly, to improving the application startup speed by dividing an application launch process using an efficient pool management technique.

Background Art

[0002] The Internet of Things (IoT) technology enables functionality expansion by providing the ability to add additional applications to in-vehicle devices (e.g., navigation systems). In addition, application development in vehicles is expanding to enable applications to control system functions within the vehicle (e.g., dashboard cameras, air conditioning units, vehicle information management). These applications are developed as an integral part of the core functionality of the in-vehicle device, enabling system functions that can be installed as replaceable applications within the in-vehicle device.

Summary of the Invention

[0003] Various embodiments of the present disclosure relate to a computer-implemented method for pre-pooling virtual machine components prior to application startup. The computer-implemented method includes reading a virtual machine pool manifest by a virtual machine pool manager. The virtual machine pool manifest includes an initial number of virtual machines to be started. The virtual machine pool manifest may further include parameters indicating the number of virtual machines for which resources are to be allocated, the number of resources to be allocated based on the virtual machine resource definition, the number of virtual machines without resource allocation, the default environment, and the maximum number of applications executable at a given time. The computer-implemented method further includes sending a plurality of base virtual machines to the virtual machine pool based on the initial number provided by the virtual machine pool manifest. The base virtual machines lack an initial application assignment. The computer-implemented method further includes allocating initial resources to a portion of the base virtual machines based on the virtual machine resource definition in the virtual machine pool manifest. The computer-implemented method includes loading a core program package into a portion of the base virtual machines.

[0004] Additional embodiments of the present disclosure include a computer program product that pre-pools virtual machine components prior to application startup, which can include a computer-readable storage medium having program instructions embodied thereon, the program instructions being executable by a processor to cause the processor to execute a method. The method includes reading a virtual machine pool manifest by a virtual machine pool manager. The virtual machine pool manifest includes an initial number of virtual machines to be started. The virtual machine pool manifest can further include parameters indicating the number of virtual machines for which resources are to be allocated, the number of resources to be allocated based on the virtual machine resource definition, the number of virtual machines without resource allocation, the default environment, and the maximum number of applications executable at a given time. The method further includes sending a plurality of base virtual machines to the virtual machine pool based on the initial number provided by the virtual machine pool manifest. The base virtual machines lack an initial application allocation. The method further includes allocating initial resources to a portion of the base virtual machines based on the virtual machine resource definition in the virtual machine pool manifest. The method includes loading a core program package to a portion of the base virtual machines.

[0005] Further embodiments relate to a virtual machine pool management system configured to execute the above-described method for pre-pooling virtual machine components prior to application startup. This summary is not intended to represent all embodiments or all implementations of the present disclosure, or both.

[0006] These and other features, aspects, and advantages of the embodiments of the present disclosure will be better understood with reference to the following description, the appended claims, and the accompanying drawings.

Brief Description of the Drawings

[0007]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

[0008] The present disclosure can accept various modifications and alternative forms, and details thereof are shown by way of example in the drawings and will be described in detail. However, it should be understood that the intention is not to limit the specific embodiments described. On the contrary, the intention is to include all modifications, equivalents, and alternatives within the scope of the present disclosure. In the accompanying drawings, like reference numerals are used to indicate like parts.

[0009] The present disclosure relates to the application startup speed in an in-vehicle device, and more particularly, to improving the application startup speed by splitting the application startup process using an efficient pool management technique. The present disclosure is not necessarily limited to such applications, but various aspects of the present disclosure can be recognized through discussions of various examples using this context.

[0010] The Internet of Things (IoT) technology enables functional scalability by providing the ability to add additional applications to in-vehicle devices of a vehicle (e.g., a navigation system). In addition, application development in vehicles is expanding to enable applications to control system functions within the vehicle (e.g., dashboard camera, air conditioner, vehicle information management). These applications are developed as an essential part of the core functions of in-vehicle devices, enabling system functions that can be installed as replaceable applications within the in-vehicle devices.

[0011] A typical startup procedure for an in-vehicle application includes first initializing an application platform or core program for operating the application. The initialization process includes reading the application from a storage device, generating a process, starting the core program of the application, and allocating resources required by the application. When control is transferred to the application logic, the application is started.

[0012] However, in-vehicle devices have limited resources (e.g., memory, storage, processor), so there remains a restriction on application startup. Therefore, in-vehicle applications may have upper limits on resources. Current technologies for accelerating application startup include techniques such as hibernation. In hibernation, the operating system can copy the execution state of an application to memory before powering off. As a result, the operating system can restart the application by restoring the copy of the execution state when powering on. However, in a vehicle, power-off is triggered by an accessory-off command, which may not provide the operating system with an opportunity to create a copy of the execution state of all applications that may be running. Further, in contrast to conventional computing devices, there is no distinction between different types of power-off in in-vehicle devices. For example, a notebook computer can distinguish power-off commands. A power-off command by pressing the power button can elicit a different response from the notebook compared to a power-off command when the notebook is closed. By distinguishing different types of power-off, the operating system of such a device can be made to hibernate currently running applications when the device goes to sleep as opposed to shutting down. Since in-vehicle devices cannot distinguish between sleep-type power-off events and shutdown power-off events, techniques such as hibernation, for example, are not applicable to in-vehicle devices.

[0013] Other techniques, such as improving hardware performance and program execution speed using ahead-of-time compilers (AOT), also attempt to speed up application startup. However, these techniques may incur additional overhead costs and provide only limited improvement to the overall startup speed of in-vehicle applications.

[0014] Embodiments of the present disclosure can overcome the above and other problems by using a virtual machine pool management system for pre-pooling virtual machine components before application startup. Additionally, resource allocation and application logic shifting are performed on the application. Thereby, the application pool management system can speed up the startup time of applications in the in-vehicle device. The virtual machine pool management system includes a virtual machine pool manager configured to manage and start the virtual machines required by the in-vehicle device. The virtual machine pool manager is also configured to allocate initial resources to the virtual machines based on a virtual machine pool manifest. The virtual machine pool management system further includes an application package manager configured to install and load a core program package onto the virtual machines to which resources have been allocated. These virtual machines can remain in the virtual machine pool and be in a ready state until they are requested by the in-vehicle device to execute an application.

[0015] In some embodiments, the virtual machine pool management system can start additional virtual machines that have not received resource allocations. The virtual machine pool management system can put these virtual machines into a standby configuration until they are needed. In this way, when resources become available, the virtual machine pool manager can allocate resources to the virtual machines in the standby configuration and put these virtual machines into a ready configuration.

[0016] In some embodiments, the virtual machine pool manager allocates initial resources to virtual machines based on a resource allocation pattern. The resource allocation pattern can represent a typical pattern that an in-vehicle device has during operation. For example, the in-vehicle device can execute five applications immediately after startup and then execute another six applications after a predetermined time. The resource allocation pattern can mimic the needs of the in-vehicle device to anticipate its needs.

[0017] Embodiments of the present disclosure include an application life cycle manager configured to manage the life cycle of applications executed on an in-vehicle device. Additionally, the application life cycle manager can determine which virtual machine to allocate an application to. This can be based on the initial resources loaded on the virtual machine and the core programming. For example, if a virtual machine is allocated a sufficient amount of resources to enable the operation and execution of the requested application, the application life cycle manager can select that virtual machine and allocate that specific application to it. Otherwise, the application life cycle manager can request that the virtual machine pool manager start additional virtual machines or reallocate appropriate resources.

[0018] Next, referring to FIG. 1, a high-level block diagram of a vehicle 100 equipped with an embedded in-vehicle device 105 is shown. Additionally, the vehicle 100 includes sensors 160 and a camera 170. The in-vehicle device 105 includes a control unit 110, a storage unit 120, a communication unit 130, an input unit 140, and an output unit 150. The input unit 140 is communicatively connected to the sensors 160 and the camera 170.

[0019] The in-vehicle device 105 is a component of the vehicle 100 configured to receive and transmit information related to the vehicle 100. In addition, the in-vehicle device 105 can operate vehicle system functions such as drive mode, cruise control, camera, sensors, headlights, etc. The in-vehicle device 105 can also implement various vehicle controls. These vehicle controls include, for example, navigation control, heating, ventilation, and air conditioning (HVAC) control, as well as audio / video (A / V) entertainment control.

[0020] The control unit 110 is a component of the in-vehicle device 105 configured to use one or more central processing units (CPUs) or multi-core CPUs, and includes a read-only memory (ROM), a random access memory (RAM), an input / output interface, a timer, etc. The control unit 110 is a decision-making unit that controls the operation of each component unit by executing a program stored in the embedded ROM, and executes the virtual machine pool management system 200 described below.

[0021] The storage unit 120 is a component of the in-vehicle device configured to store information related to the vehicle 100 and the in-vehicle device 105. In some embodiments, the storage unit 120 is a non-volatile memory (e.g., flash memory, electrically erasable programmable read-only memory (EEPROM)). The storage unit 120 can include one or more memories. Each memory of the storage unit 120 is, for example, a semiconductor memory, a magnetic memory, a solid-state memory, or an optical memory. Each memory functions, for example, as a main storage device, an auxiliary storage device, or a cache memory. The storage unit 120 can store information used for the operation of the in-vehicle device 105. For example, the storage unit 120 can store applications executable by the in-vehicle device 105.

[0022] The communication unit 130 is a component of the in-vehicle device 105 configured to exchange data with a server. The communication device 130 has one or more communication modules. The communication modules include, for example, modules compatible with mobile communication standards such as the fourth generation (4G), fifth generation (5G), Bluetooth, Wi-Fi, Global System for Mobile Communications (GSM), Code Division Multiple Access (CDMA), Long-Term Evolution (LTE), Infrared (IR), and the like. In addition, the communication unit can have a communication device such as a Data Communication Module (DCM). The communication unit 130 connects the in-vehicle device 105 to a network and communicates with the server. In some embodiments, the communication unit 130 includes a communication module that is a Global Positioning System (GPS) receiver module, and the in-vehicle device 105 receives GPS signals with the communication unit 130.

[0023] The input unit 140 is a component of the in-vehicle device 105 that is an interface for inputting signals from outside the in-vehicle device 105. The input unit 140 can receive information from the sensor 160 or the camera 170, and the control unit 110 can obtain information from the sensor 160 and the camera 170.

[0024] The output unit 150 is a component of the in-vehicle device configured to output a signal indicating an operational function capable of being performed by the vehicle 100. In some embodiments, the output unit 150 can be the communication unit 130 connected to a Local Area Network (LAN) or the communication unit 130 combined with the input unit 140.

[0025] Note that FIG. 1 is intended to show the main representative components of an exemplary in-vehicle device 105. However, in some embodiments, the individual components may have a greater or lesser complexity than those represented in FIG. 1, there may be components other than or in addition to those shown in FIG. 1, and the number, type, and configuration of such components may vary.

[0026] FIG. 2 is a block diagram showing a virtual machine pool management system 200 for pre-pooling virtual machine components before application startup according to an embodiment of the present disclosure. The virtual machine pool management system 200 includes a virtual machine pool manager 210, a virtual machine pool manifest 220, a virtual machine pool 230, an application life cycle manager 240, applications 250-1, 250-2, 250-N (collectively referred to as "applications 250") (where N is a variable integer representing the number of possible applications 250), and an application package manager 260. The virtual machine pool includes base virtual machines 233-1, 233-2, 233N (collectively referred to as "base virtual machines 233") (where N is a variable integer representing the number of possible base virtual machines 233) and resources 235-1, 235-2, 235N (collectively referred to as "resources 235") (where N is a variable integer representing the number of possible resources 235). The application life cycle manager 240 includes an application logic injection manager 244 and an application resource assigner 248. The applications 250 include resource information 251-1, 251-2, 251-N (collectively referred to as "resource information 251") (where N is a variable integer representing the number of possible resource information 251).

[0027] The virtual machine pool manager 210 is a component of the virtual machine pool management system 200 configured to manage and launch virtual machines. The virtual machine pool manager 210 is responsible for resource management of the virtual machines. It can maintain a list of which designated applications 250 operate on which base virtual machines 233. For example, the list can have an entry indicating that the navigation software operates on a navigation-specific virtual machine and another entry indicating that a non-user interface (UI) application operates on a non-UI-specific virtual machine.

[0028] The virtual machine pool manager 210 can execute a series of virtual machine management utilities. These utilities include, for example, functions to create, destroy, put to sleep, and wake up virtual machines. The utilities can also maintain a list that matches applications to virtual machines.

[0029] The virtual machine pool manifest 220 is a component of the virtual machine pool management system 200 configured to provide initial virtual machine establishment requirements. The virtual machine pool manifest 220 can include the initial number of base virtual machines 233 to be placed in the virtual machine pool 230. For example, the initial number can indicate that seven base virtual machines 233 are required at startup. Additionally, the virtual machine pool manifest 220 can include the number of base virtual machines 233 to which resources 235 should be allocated.

[0030] In some embodiments, the virtual machine pool manifest 220 indicates the allocation of resources 235 based on resource definitions. The resource definitions define the types of resources required based on the type of application loaded on the virtual machine 233. For example, the resource definitions can indicate the resources required for a display buffer. The display buffer can indicate that an application requires the use of the UI. Applications that may require the UI include, for example, navigation, radio, system settings, speedometer, etc. Another resource definition may indicate that the display buffer is not used, which may indicate that fewer resources are required for a particular application. These types of applications may be background-related applications that the in-vehicle device 105 may use during the operation of the vehicle 100.

[0031] In some embodiments, the virtual machine pool manifest 220 includes default environment resource allocations. The default environment resource allocations can include the default allocation of resources when no resource definition is defined for a particular virtual machine. The default resource allocation can indicate the amount of memory, storage, and CPU usage to be allocated to the default base virtual machine 233.

[0032] In some embodiments, the virtual machine manifest 220 includes a parameter indicating the threshold number of applications that the in-vehicle device 105 can execute at a given time. The threshold number can be based on the resources available to the in-vehicle device 105 and manageable by the virtual machine pool management system 200.

[0033] The virtual machine pool 230 is a component of the virtual machine pool management system 200 configured to store the base virtual machines 233. The virtual machine pool 230 can be any storage capable of storing software. In some embodiments, the virtual machine pool 230 stores a single virtual machine that can be configured by the virtual machine pool manager 210. The virtual machine pool 230 can store any number of distinct base virtual machines 233 that can be configured by the virtual machine pool manager 210.

[0034] The base virtual machine 233 is a component of the virtual machine pool management system 200 configured to emulate the performance of a device (e.g., a computer). The base virtual machine 233 can be retrieved from the virtual machine pool 230. The base virtual machine 233 includes the resources 235 required to operate the base virtual machine 233. For example, the resources include the amount of memory, storage, and CPU usage required by the base virtual machine 233. Additionally, the base virtual machine 233 can further include a core program package that is loaded into the base virtual machine 233 after being sent out to the virtual machine pool 230. The core program package can provide the base operating system required to support and execute the application 250 as well as various application components included in the base virtual machine 233.

[0035] In some embodiments, the base virtual machine 233 includes a client that communicates with a server. The client can communicate with the server via the base virtual machine 233 to create, clone, or otherwise access virtual machine instances according to various configuration definitions included in the virtual machine pool manifest 220.

[0036] The Application Life Cycle Manager 240 is a component of the virtual machine pool management system 200 configured to manage the life cycle of the application 250. The Application Life Cycle Manager 240 can request to load an application onto the base virtual machine 233. Additionally, the Application Life Cycle Manager 240 can determine which applications are to be loaded and in what order the applications are to be loaded. In some embodiments, the Application Life Cycle Manager 240 requests additional base virtual machines 233 to be added to the virtual machine pool 230. For example, there may be a very large number of applications 250 in operation, and to avoid a slowdown in operation, the Application Life Cycle Manager 240 can allocate resources to a base virtual machine 233 in standby mode and request that the core program package be loaded. The additional base virtual machines 233 may also be started within the virtual machine pool 230 and placed in a standby mode configuration. These base virtual machines 233 may have no resources or program logic allocated to them.

[0037] The Application Logic Injection Manager 244 is a component of the Application Life Cycle Manager 240 configured to load proprietary application logic onto the base virtual machine 233. The Application Logic Injection Manager 244 can identify the application 250 to be loaded onto the base virtual machine 233 and can load application-specific information to enable the execution of the application 250. For example, an application class can be loaded and an injection point can be attached to a receptacle of the base virtual machine 233.

[0038] The application resource allocator 248 is a component of the application life cycle manager 240 configured to allocate resources required by the application 250 to the virtual machine 233. The application resource allocator 248 can compare the initial resources allocated to the base virtual machine 233 with the resource information 251 of the application 250 loaded on the virtual machine 233. If the resources 235 are different, the application resource allocator 248 can re-allocate the resources to the virtual machine 233. For example, the base virtual machine 233 can include 50 megabytes of storage, and if the application 250 loaded on the base virtual machine 233 requires 65 megabytes of storage, the application resource allocator 248 can re-allocate at least 65 megabytes of storage to the base virtual machine 233 to enable the application to be loaded and executed.

[0039] In some embodiments, if the initial resources appropriately provide sufficient resources based on the resource information 251 of the application 250, the application resource allocator 248 does not re-allocate any resources. In some embodiments, if the initial resources appropriately provide sufficient resources based on the resource information 251 of the application 250, the application resource allocator 248 evaluates the resources and releases the allocation of unnecessary resources. For example, if the initial resources include 200 kilobytes of memory and the application 250 only requires 100 kilobytes of memory, the application resource allocator 248 can release the allocation of at most 100 kilobytes of memory from the virtual machine 233.

[0040] The application 250 is the software of the virtual machine pool management system 200 that can be executed by the in-vehicle device 105. The application includes functions such as telematics services, road information, traffic information, weather information, fleet management, health diagnosis, emergency support, music / video, insurance, news, and infotainment. Each application 250 additionally includes resource information 251 related to the application 250. The resource information 251 can include the number of resources required to execute and operate a specific application 250. For example, an application 250 that provides weather information may require a specific amount of memory, storage, and CPU usage that the resource information 251 can store.

[0041] The application package manager 260 is a component of the virtual machine pool management system 200 configured to install and update the application 250 provided by the virtual machine pool management system 200. The application package manager 260 can automate the process of installing, upgrading, configuring, and removing the application 250 from the in-vehicle device 105. The application package manager 260 can handle packages that are distributions of software and data in archive files. The package can include metadata such as the name of the application 250, a description of its purpose, version number, vendor, checksum, and a list of dependencies (e.g., resource information 251) required for the application 250 to operate properly. At installation, the metadata can be stored in a local package database. The application package manager 260 can maintain a database of the dependencies and version information of the application 250 to prevent software inconsistencies and missing prerequisites.

[0042] Note that FIG. 2 is intended to show the main representative components of an exemplary virtual machine pool management system 200. However, in some embodiments, the individual components may have a greater or lesser complexity than those represented in FIG. 2, there may be components other than or in addition to those shown in FIG. 2, and the number, type, and configuration of such components may vary.

[0043] FIG. 3 is a flowchart showing a process 300 for pre-pooling virtual machine components prior to application startup according to an embodiment of the present disclosure. Process 300 begins when virtual machine pool manager 210 reads virtual machine pool manifest 220 at the start of virtual machine pool management system 200. This is shown in step 310. Virtual machine pool manager 210 can read the requirements of the initial virtual machines 233. These requirements can include, for example, the initial number of base virtual machines 233 to be placed in virtual machine pool 230, the allocation of resources 235 for each virtual machine 233 based on resource definitions, the default environmental resource allocation, and a parameter indicating the maximum number of applications that in-vehicle device 105 can run at a given time.

[0044] The virtual machine pool manager 210 sends the base virtual machine 233 to the virtual machine pool 230 as shown in the virtual machine pool manifest 220. This is shown in step 320. The virtual machine pool 230 can store any number of distinct base virtual machines 233 that can be configured by the virtual machine pool manager 210. At startup, the base virtual machine 233 lacks resource allocation and the core program package is not loaded. In some embodiments, the base virtual machine 233 is started according to the timeline indicated by the virtual machine pool manifest 220. For example, the virtual machine pool manifest 220 can indicate that 12 base virtual machines 233 are started at startup and then another 5 base virtual machines 233 are started after a predetermined time. This series of predetermined startups of the base virtual machine 233 can be done the number of times configured by the virtual machine pool manifest 220.

[0045] The virtual machine pool manager 210 allocates the initial resources 235 to some of the base virtual machines 233 started in step 320. This is shown in step 330. The base virtual machines 233 to which the resources 235 are allocated can be predetermined by the virtual machine pool manifest 220. The number of base virtual machines 233 to which further resources are allocated can also be optimized based on the number of applications 250 required by the vehicle 100 at startup. These applications include, for example, telematics services, road information, traffic information, weather information, fleet management, health diagnosis, emergency assistance, music / video, insurance, news, and infotainment. The remaining part of the base virtual machine 233 can be placed in a standby configuration until such time as it is needed.

[0046] By placing the base virtual machine 233 in a standby configuration, the virtual machine pool management system 200 does not need to spend additional time starting up the virtual machine 233 when the application 250 needs to be launched. Additionally, not all of the base virtual machines 233 to which resources 235 are allocated will immediately have an application allocated to them. Instead, they can function as a buffer during the operation of the in-vehicle device 105. When the base virtual machine 233 is requested and used by the application 250, more virtual machines can be sent out to the virtual machine pool 230 to maintain the buffer and speed up the startup process of the application 250.

[0047] The application package manager 260 loads the core program package into the portion of the base virtual machine 233 to which resources 235 are allocated. This is shown in step 340. The core program package can include a Java(R) virtual machine environment without application logic. Other core program packages can include, for example, virtual machine base code, class libraries (e.g., Java(R)), service application programming interfaces (APIs), and UI life cycle management software. The core program package can include a receptacle that can represent a shell for loading application logic. After the virtual machine 233 is allocated resources 235 and the core program package is loaded, it can be placed in a ready configuration and an application can be allocated and loaded.

[0048] The application life cycle manager 240 assigns the application 250 to the base virtual machine 233 in the ready configuration. This is shown in step 350. In some embodiments, the application life cycle manager 240 can determine which application is loaded in the order in which the applications are loaded. The order in which the application life cycle manager 240 selects and assigns the application 250 can be based on the urgency requirements of the application 250 required by the in-vehicle device 105. For example, an application 250 that performs system diagnostics when the vehicle 100 is started can have the virtual machine 233 assigned before the application 250 provides infotainment to the passengers.

[0049] In some embodiments, the application life cycle manager 240 assigns an application to the base virtual machine 233 in the ready configuration based on the application type associated with the running application 250. For example, an application 250 that does not require a UI can be started first because the resource information 251 of the application 250 is consistent with the resource information of the initial resources 235 assigned to the base virtual machine 233. Therefore, there is no need to reassign additional resources 235 to the virtual machine 233, and the application 250 can be started faster than an application 250 that may require additional resources.

[0050] The application logic injection manager 244 starts the application 250 in the base virtual machine 233. This is shown in step 360. The application logic includes, for example, application-specific classes, methods, and additional code. The application logic injection manager 244 can load the application logic related to the application 250 into the virtual machine 233. In addition, the injection point can be attached to a receptor included in the virtual machine 233 where the core program package is loaded.

[0051] In some embodiments, the application resource allocator 248 analyzes the resource information 251 of the application 250 and the initial resources 235 allocated to the virtual machine 233. Based on the analysis, the application resource allocator can re-allocate the resources 235 to the virtual machine 233 to successfully start the application. For example, if the initial resources 235 include 45 kilobytes of available memory and 100 kilobytes of memory are required to start the application 250, the application resource allocator 248 can re-allocate additional memory to the virtual machine 233 so that the application 250 can be properly started.

[0052] In some embodiments, the application resource allocator 248 analyzes the resource information 251 of the application 250 and the initial resources 235 allocated to the virtual machine 233. Based on the analysis, the application resource allocator can return the unnecessary resources 235 to the resource pool for reallocation. When the application logic is loaded into the application 250 and the injection points are attached, the application life cycle manager 240 executes the application 250. This is shown in step 370. The application life cycle manager 240 monitors the application 250 during operation and execution and determines whether the application 250 should be terminated and when it should be terminated.

[0053] Referring now to FIG. 4, a high-level block diagram of an exemplary computer system 400 (e.g., virtual machine pool management system 200) that may be used in implementing one or more of the methods, tools, and modules described herein, and related functions, in accordance with embodiments of the present disclosure, is shown. In some embodiments, the main components of the computer system 400 can include one or more processors 402, a memory 404, a terminal interface 412, an I / O (input / output) device interface 414, a storage interface 416, and a network interface 418, all of which can be communicatively coupled directly or indirectly for component-to-component communication via a memory bus 403, an I / O bus 408, and an I / O bus interface 410.

[0054] Computer system 400 can include one or more general-purpose programmable central processing units (CPUs) 402-1, 402-2, 402-3, and 402-N, which are collectively referred to herein as processor 402. In certain embodiments, computer system 400 may include a large number of processors typical of relatively large systems, however, in other embodiments, computer system 400 may alternatively be a single CPU system. Each processor 402 can execute instructions stored in memory 404 and can include one or more levels of on-board cache.

[0055] Memory 404 can include computer system-readable media in the form of volatile memory such as random access memory (RAM) 422 or cache memory 424. Computer system 400 can further include other removable / non-removable volatile / non-volatile computer system storage media. By way of example only, storage system 426 may be provided for reading from and writing to a non-removable non-volatile magnetic medium such as a "hard drive". Although not shown, a magnetic disk drive for reading from and writing to a removable non-volatile magnetic disk (e.g., a "floppy (R) disk"), or an optical disk drive for reading from and writing to a removable non-volatile optical disk such as a CD-ROM, DVD-ROM, or other optical media may be provided. Additionally, memory 404 can include flash memory, e.g., a flash memory stick drive, or a flash drive. The memory device can be connected to memory bus 403 by one or more data media interfaces. Memory 404 can include at least one program product having a set of program modules (e.g., at least one) configured to execute the functions of various embodiments.

[0056] Memory bus 403 is shown in FIG. 4 as a single bus structure that provides a direct communication path between processor 402, memory 404, and I / O bus interface 410. However, memory bus 403 can, in some embodiments, include a number of different buses or communication paths, which can be configured in various forms such as hierarchical, star, or web configurations of point-to-point links, multiple hierarchical buses, parallel and redundant paths, or other suitable types of configurations. Further, although I / O bus interface 410 and I / O bus 408 are shown as single respective units, computer system 400 can, in some embodiments, include a number of I / O bus interface units, a number of I / O buses, or both. Further, although a number of I / O interface units are shown that separate I / O bus 408 from various communication paths extending to various I / O devices, in other embodiments, some or all of the I / O devices may be directly connected to one or more system I / O buses.

[0057] In some embodiments, computer system 400 can be a multi-user mainframe computer system, a single-user system, or a server computer or similar device that has little or no direct user interface but receives requests from other computer systems (clients). Further, in some embodiments, computer system 400 can be implemented as a desktop computer, a portable computer, a laptop or notebook computer, a tablet computer, a pocket computer, a telephone, a smartphone, a network switch or router, or other suitable type of electronic device.

[0058] Note that FIG. 4 is intended to show the main representative components of an exemplary computer system 400. However, in some embodiments, the individual components may have a greater or lesser complexity than those represented in FIG. 4, there may be components other than or in addition to those shown in FIG. 4, and the number, type, and configuration of such components may vary.

[0059] One or more programs / utilities 428, each having at least one set of program modules 430 (e.g., virtual machine pool management system 200), can be stored in memory 404. The programs / utilities 428 can include a hypervisor (also called a virtual machine monitor), one or more operating systems, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data, or some combination thereof, can include embodiments of a networking environment. The programs 428 or the program modules 430, or both, generally execute the functions or methods of the various embodiments.

[0060] Although this disclosure includes a detailed description of cloud computing, it should be understood that the embodiments of the teachings detailed herein are not limited to a cloud computing environment. Rather, embodiments of the invention can be implemented with any other type of computer environment now known or later developed.

[0061] Cloud computing is a service delivery model that enables convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with a service provider. This cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

[0062] The characteristics are as follows.

[0063] On-demand self-service: Cloud consumers can provision computing capabilities, such as server time and network storage, automatically as needed, without the need for human interaction with the service provider.

[0064] Broad network access: The capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin-client platforms or thick-client platforms (e.g., mobile phones, laptops, and PDAs).

[0065] Resource pooling: The provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, and different physical and virtual resources are dynamically assigned and reassigned according to demand. Consumers generally have no control or knowledge of the exact location of the provided resources, but may have a sense of location independence in that they can specify the location at a higher level of abstraction (e.g., country, state, or data center).

[0066] Rapid flexibility: The function can be provisioned quickly, flexibly, and in some cases automatically, to scale out promptly and be released quickly to scale in promptly. To consumers, the functions available for provisioning often appear to be unlimited and can be purchased in any amount at any time.

[0067] Usage-based services: The cloud system automatically controls and optimizes resource usage by leveraging measurement functions at an abstraction level suitable for the type of service (e.g., storage, processing, bandwidth, and active user accounts). It can monitor, control, and report resource usage to provide transparency to both the provider and consumers of the services utilized.

[0068] The service model is as follows.

[0069] Software as a Service (SaaS): The function provided to consumers is to use the provider's applications running on the cloud infrastructure. The applications are accessible from various client devices through a thin-client interface such as a web browser (e.g., web-based email). Consumers do not manage or control the underlying cloud infrastructure, including the network, servers, operating system, storage, or even individual application functions, except for limited user-specific application configuration possibilities.

[0070] Platform as a Service (PaaS) as a service: The function provided to the consumer is to deploy consumer-created or acquired applications created using programming languages and tools supported by the provider onto the cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure including the network, server, operating system, or storage, but controls the deployed applications and, according to some, the application hosting environment configuration.

[0071] Infrastructure as a Service (IaaS) as a service: The function provided to the consumer is to provision processing, storage, network, and other basic computing resources, and the consumer can deploy and run any software that may include an operating system and applications. The consumer does not manage or control the underlying cloud infrastructure, but controls the operating system, storage, deployed applications, and, according to some, selectively controls the selected networking components (e.g., host firewall).

[0072] The deployment model is as follows.

[0073] Private cloud: The cloud infrastructure is operated only for an organization. The cloud infrastructure may be managed by the organization or a third party and may exist on-premises or off-premises.

[0074] Community cloud: The cloud infrastructure is shared by several organizations and supports a specific community with shared concerns (e.g., missions, security requirements, policies, and compliance considerations). The cloud infrastructure may be managed by the organization or a third party and may exist on-premises or off-premises.

[0075] Public cloud: The cloud infrastructure is made available to the general public or a large industry group and is owned by an organization that sells cloud services.

[0076] Hybrid cloud: The cloud infrastructure is a combination of two or more clouds (private, community, or public), which remain distinct entities but are joined by standard or proprietary technologies (e.g., cloud bursting for load balancing between clouds) that enable data and application portability.

[0077] Cloud computing environments are service-oriented, emphasizing statelessness, loose coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0078] Next, referring to FIG. 5, an exemplary cloud computing environment 500 is shown. As illustrated, cloud computing environment 500 includes one or more cloud computing nodes 510 that can communicate with a local computing device used by a cloud consumer, such as a personal digital assistant (PDA) or cellular phone 520-1, desktop computer 520-2, laptop computer 520-3, or in-vehicle computer system 520-4, or a combination thereof. Nodes 510 can communicate with each other. Nodes 510 may be physically or virtually grouped in one or more networks such as the private, community, public, or hybrid clouds described above, or a combination thereof (not shown). Thereby, cloud computing environment 500 can provide infrastructure, platform, software, or a combination thereof as a service such that a cloud consumer need not maintain resources on a local computing device. It is intended that the types of computing devices 520-1 through 520-4 shown in FIG. 5 are merely exemplary, and that computing nodes 510 and cloud computing environment 500 can communicate with any type of computerized device via any type of network or network addressable connection, or both (e.g., using a web browser).

[0079] Next, referring to FIG. 6, a set of functional abstractions 600 provided by cloud computing environment 500 (see FIG. 5) is shown. It should be understood in advance that the components, layers, and functions shown in FIG. 6 are merely exemplary and that embodiments of the invention are not limited thereto. As illustrated, the following layers and corresponding functions are provided.

[0080] The hardware and software layer 610 includes hardware components and software components. Examples of hardware components include mainframe 611, RISC (Reduced Instruction Set Computer) architecture-based server 612, server 613, blade server 614, storage device 615, and network and networking components 616. In some embodiments, software components include network application server software 617 and database software 618.

[0081] The virtualization layer 620 provides an abstraction layer that can include the following examples of virtual entities: virtual server 621, virtual storage 622, virtual network 623 including a virtual private network, virtual applications and operating systems 624, and virtual client 625.

[0082] In one example, the management layer 630 can provide the following functions. Resource provisioning 631 dynamically procures computing resources and other resources utilized to execute tasks within a cloud computing environment. Metering and pricing 632 performs cost tracking when resources are utilized within a cloud computing environment and sends invoices or bills for the consumption of these resources. In one example, these resources can include application software licenses. Security performs identity verification of cloud consumers and tasks, as well as protection of data and other resources. User portal 633 provides access rights to the cloud computing environment to consumers and system administrators. Service level management 634 performs cloud computing resource allocation and management such that the required service levels are met. Service quality assurance contract (SLA) planning and fulfillment 635 performs advance preparation and procurement of cloud computing resources for which future requirements are anticipated by the SLA.

[0083] The workload layer 640 provides examples of functions that can utilize a cloud computing environment. Examples of workloads and functions that can be provided from this layer include mapping and navigation 641, software development and life cycle management 642 (e.g., virtual machine pool management system 200), virtual classroom education delivery 643, data analysis processing 644, transaction processing 645, and precision cohort analysis 646.

[0084] The present invention can be a system, method, or computer program product, or a combination thereof, in the integration of any possible technical detail level. The computer program product can include one computer-readable storage medium (or a plurality of media) having computer-readable program instructions for causing a processor to execute aspects of the present invention.

[0085] A computer-readable storage medium can be a tangible device that holds and stores instructions for use by an instruction-executing device. The computer-readable storage medium can be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy (R) disk, mechanically encoded devices such as punch cards or raised structures in grooves having instructions recorded thereon, and any suitable combination of the foregoing. As used herein, a computer-readable storage medium should not be construed to be a transitory signal per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., optical pulses passing through an optical fiber cable), or electrical signals transmitted through a wire.

[0086] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to respective computing / processing devices, or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network can include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface of each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions for storage on a computer-readable storage medium within each respective computing / processing device.

[0087] The computer-readable program instructions for carrying out the operations of the present invention may be written in any combination of one or more programming languages, including assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuits, or source code or object code written in any combination of object-oriented programming languages such as Smalltalk(R), C++, and procedural programming languages such as the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer, or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (e.g., through the Internet using an Internet service provider). In some embodiments, for example, an electronic circuit including a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA) may execute the computer-readable program instructions by utilizing the state information of the computer-readable program instructions to customize the electronic circuit for exclusive use to carry out aspects of the present invention.

[0088] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0089] These computer-readable program instructions are provided to a processor of a computer or other programmable data processing apparatus to produce a means for causing the instructions executed via the processor of the computer or other programmable data processing apparatus to implement the functions / operations specified in one or more blocks of a flowchart, a block diagram, or both, thereby bringing about a machine. These computer-readable program instructions may also be stored in a computer-readable storage medium that includes instructions for implementing the aspects of the functions / operations specified in one or more blocks of a flowchart, a block diagram, or both, such that the computer-readable storage medium constitutes a product that, when instructed in a particular manner, can function in a computer, a programmable data processing apparatus, or other device, or a combination thereof.

[0090] The computer-readable program instructions may also be loaded onto a computer, other programmable apparatus, or other device such that the instructions executed on the computer, other programmable data processing apparatus, or other device implement the functions / operations specified in one or more blocks of a flowchart, a block diagram, or both, thereby causing a series of operational steps to be executed on the computer, other programmable apparatus, or other device, and thereby bringing about a computer-implemented process.

[0091] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible embodiments of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagram can represent a module, segment, or portion of instructions that include one or more executable instructions for implementing the specified logical function. In some alternative embodiments, the functions noted in the blocks may be performed out of the order noted in the figures. For example, two blocks shown in succession may in fact be performed as one step that is executed simultaneously, substantially simultaneously, partially or wholly in a temporally overlapping manner, or sometimes in the reverse order depending on the relevant functions. It should also be noted that each block of the block diagram or flowchart diagram, or both, and combinations of blocks of the block diagram or flowchart diagram, or both, can be implemented by a dedicated hardware-based system that performs the specified function or operation or by a combination of dedicated hardware instructions and computer instructions.

[0092] The terms used in this specification are for the purpose of describing particular embodiments only and are not intended to limit the various embodiments. As used in this specification, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. The terms "includes", "including", or both, when used in this specification, specify the presence of the stated feature, integer, step, operation, element, or component, or combination thereof, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or groups thereof, or combinations thereof. In the following detailed description of exemplary embodiments of the various embodiments, reference is made to the accompanying drawings (like numerals represent like elements) that form a part of this specification, and in which are shown by way of illustration specific exemplary embodiments in which the various embodiments may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the embodiments, but other embodiments may be used and logical, mechanical, electrical, and other changes may be made without departing from the scope of the various embodiments. In the preceding description, numerous specific details are set forth in order to provide a thorough understanding of the various embodiments. However, the various embodiments may be practiced without these specific details. In other instances, well-known circuits, structures, and techniques have not been shown in detail so as not to obscure the embodiments.

[0093] If different reference numbers include a common number followed by different letters (e.g., 100a, 100b, 100c), or a comma followed by different numbers (e.g., 100-1, 100-2, or 100.1, 100.2), the use of only the reference number without the following letter or number (e.g., 100) can refer to the entire group of elements, any subset of the group, or an exemplary sample of the group.

[0094] Furthermore, the phrase "at least one of" when used with a list of items means that one or more different combinations of the listed items may be used and that only one of each item in the list may be required. In other words, "at least one of" means that any combination and any number of items from the list may be used, but not all of the items in the list are required. The items can be specific objects, things, or categories.

[0095] For example, and not by way of limitation, "at least one of item A, item B, or item C" can include item A, item A and item B, or item B. This example can also include item A, item B, and item C, or item B and item C. Of course, any combination of these items can also exist. In some illustrative examples, "at least one of" can be, for example and not by way of limitation, two item As, one item B, and ten item Cs, four item Bs and seven item Cs, or other suitable combinations.

[0096] Different instances of the term "embodiment" as used herein do not necessarily refer to the same embodiment, but may do so. Any data and data structures illustrated or described herein are merely examples, and in other embodiments, different amounts of data, types of data, fields, number and types of fields, field names, number and types of rows, records, entries, or data compilations may be used. Additionally, any data may be combined with logic such that a separate data structure may not be required. Therefore, the detailed description provided above should not be understood in a limiting sense.

[0097] The descriptions of various embodiments of the present invention have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terms used herein are chosen in order to best explain the principles of the embodiments, the practical application, or technical improvements found in the marketplace, or to enable those skilled in the art to understand the embodiments disclosed herein.

[0098] Although the present invention has been described with respect to specific embodiments, it is anticipated that modifications and variations thereof will become apparent to those skilled in the art. Therefore, the following claims are intended to be construed to include all such modifications and variations that are within the true spirit and scope of the present invention.

Claims

1. A computer-implemented method for pre-pooling a plurality of base virtual machines in a virtual machine pool before starting an in-vehicle application, the computer-implemented method comprising: reading, by a virtual machine pool manager, a virtual machine pool manifest at the start of a virtual machine pool management system, the virtual machine pool manifest including an initial number of base virtual machines to be placed in the virtual machine pool; sending out the plurality of base virtual machines to the virtual machine pool based on the initial number before starting the in-vehicle application; allocating initial resources to a part of the plurality of base virtual machines based on a virtual machine resource definition, the base virtual machines allocated with the resources being predetermined by the virtual machine pool manifest, and the remaining base virtual machines other than the part of the plurality of base virtual machines being put into a standby configuration until it is needed; loading a core program package into the part of the plurality of base virtual machines; allocating a first application to a first base virtual machine among the part of the plurality of base virtual machines; and then, allocating a second application to a base virtual machine in the standby configuration; and then, allocating a third application to a second base virtual machine that requires additional resources A computer-implemented method comprising the above.

2. allocating the application to the first base virtual machine from the part of the base virtual machines to an application life cycle manager based on an application type related to the application; starting the application in the first base virtual machine; executing the application The computer-implemented method according to claim 1, further comprising the above.

3. The computer-implemented method according to claim 2, wherein the allocating the application to the first base virtual machine is further based on the initial resources allocated to the first base virtual machine.

4. The starting of the application is Loading application logic related to the application, wherein the loading includes the application logic including injection points, and attaching the injection points to receptors included in the first base virtual machine, and reassigning resources to the first base virtual machine based on resource information related to the application The computer-implemented method according to any one of claims 1 to 3.

5. The virtual machine pool manifest includes the number of base virtual machines to which resources are to be allocated and the allocation of resources for each virtual machine based on the virtual machine resource definition, and the virtual machine resource definition defines the type of resources required based on the type of application loaded on the base virtual machine. The computer-implemented method according to any one of claims 1 to 4.

6. The computer-implemented method according to any one of claims 1 to 5, wherein allocating the initial resources is based on a resource allocation pattern.

7. The computer-implemented method according to any one of claims 1 to 6, wherein the core program package includes a Java (R) runtime environment.

8. The resources allocated to the virtual machine that has entered the standby configuration function as a buffer. The computer-implemented method according to any one of claims 1 to 7.

9. The computer-implemented method according to any one of claims 1 to 8, wherein the first application is based on the urgency requirement of the in-vehicle application required by the in-vehicle device implementing the in-vehicle application.

10. The computer-implemented method according to any one of claims 1 to 9, wherein the second application is an application based on the application type related to the first application.

11. The computer-implemented method according to any one of claims 1 to 10, wherein the third application is an application that requires additional resources.

12. A program for causing a processor to execute the computer-implemented method according to any one of claims 1 to 11.

13. A storage medium storing the program according to claim 12. A system for pre-pooling a plurality of base virtual machine components before starting an in-vehicle application, the system comprising: a memory; a processor; a storage storing computer-executable program code and, the computer-executable program code causes the processor to execute each step of the computer-implemented method according to any one of claims 1 to 11; a system.

Images