METHOD AND DEVICE FOR UPDATING A VIRTUAL MACHINE OPERATED ON A PHYSICAL MACHINE UNDER A HYPERVISOR

A method for updating a virtual machine operated under a hypervisor on a physical machine having a random-access memory and a read-only memory. The hypervisor operates the virtual machine under an individual diagnostic address, the read-only memory storing a machine code of the hypervisor and of the virtual machine. The virtual machine receives an updating request from an external unit under the diagnostic address with the aid of a communication infrastructure and communicates the updating request to the hypervisor, The hypervisor transfers the machine code from the read-only memory into the random-access memory. The hypervisor starts the virtual machine and executes a boot manager of the virtual machine. The boot manager receives a current machine code under the diagnostic address of the virtual machine and exchanges the machine code in the read-only memory at least partially for the current machine code, and the boot manager restarts the virtual machine.

CROSS REFERENCE

The present application claims the benefit under 35 U.S.C. §119 of German Patent Application No. DE 102015214389.9 filed on Jul. 29, 2015, which is expressly incorporated herein by reference in its entirety.

FIELD

The present invention relates to a method for updating a virtual machine operated under a hypervisor on a physical machine having a random-access memory and a read-only memory. The present invention also relates to a corresponding device, a corresponding computer program as well as a corresponding storage medium.

BACKGROUND INFORMATION

Generally, conventional vehicle control units have capabilities for on-board diagnostics. Typically, the diagnosis supplied in this context relates to the control unit itself, its functionality and software update. These capabilities of generic control units may be accessed, for instance, with the aid of many different vehicle communication networks such as CAN, Flexray or ethernet and specific diagnostic protocols such as OBD. To produce a diagnostic communications link between the control unit and an external diagnostic tool, such a control unit has a diagnostic address. In the case of a single software system within the control unit, the capabilities described can be considered state-of-the-art.

In a virtualized control unit, however, there are several software systems, what are referred to as guest systems, and the additional software components of a hypervisor. As a result, diagnostic capabilities are needed with regard to status information for each guest system, the hardware and the hypervisor. Finally, the guest systems and the hypervisor must be updated.

German Patent No. DE 19921845 A1 describes a diagnostic-test device for motor vehicles, programmable control units in the motor vehicle being provided with self-diagnostic means which, under program control, control and monitor the engine management and other systems of the motor vehicle, generate and store error codes, and which are connectable via a diagnostic/test connector on the motor-vehicle side to an external diagnostic tester. The external diagnostic tester is equipped with a program-recognition and program-loading device. With the aid of the program-recognition device, the program version contained in the connected control unit is queried and recognized. If the program present on the motor-vehicle side in the connected control unit of the vehicle and recognized via the diagnostic/test connector is not stored in the newest and most current version, the latest version in each case is then loaded by the program-loading device of the diagnostic tester into the program memory of the corresponding control unit.

SUMMARY

The present invention provides a method for updating a virtual machine operated under a hypervisor on a physical machine having a random-access memory and a read-only memory, a corresponding device, a corresponding computer program as well as a corresponding storage medium.

The design according to the present invention is based on the recognition that a virtualized system has more updatable components than a single software system. Here, there are several guest systems and the hypervisor itself, which require updating independently of each other.

An advantage of the approach according to the present invention lies in the retention of existing procedures based on diagnostic communication and diagnostic address as well as boot manager. Thus, each guest system retains its own diagnostic address, and is capable of processing diagnostic communication. The communication infrastructure may either be divided among a plurality of guest systems or reserved exclusively for one guest system.

In this context, the capability of certain embodiments of the invention to update a productive environment in operation is especially advantageous. This means that hypervisors and virtual machines together with the application programs executed by them may continue to be operated normally while a virtual machine or the hypervisor in said place is/are being updated.

The approach presented takes into account the circumstance that most control units—in automotive engineering, for instance, one may think of engine management and body control or electronic stability program—execute their machine code directly from an internal flash memory. During the flash reprogramming carried out within the course of the updating in the case of such units, by using the method described here, application code may be executed during the reprogramming. This proves to be useful in as much as a simultaneous code execution is virtually impossible using a conventional approach.

The guest system may be operated at an increased authorization level and receive the updating request in place of the hypervisor, which ultimately is updated by the boot manager or a bootloader started by it. For purposes of updating, the hypervisor is thus, as it were, assigned to a guest system. In this way, it may be updated together with this particular guest system.

According to one variant, the guest system itself may determine a possible update and initiate it. A corresponding specific embodiment proves to be largely independent of any diagnostic tool.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

FIG. 1, in a data flow chart according to the Yourdon/DeMarco notation, summarizes the basic procedure of proposed method10for updating a virtual machine18operated under a hypervisor16on a physical machine38having a random-access memory12and a read-only memory14. Hypervisor16operates virtual machine18under an individual diagnostic address, with read-only memory14storing a machine code20of hypervisor16and of virtual machine18. Virtual machine18receives an updating request24from an external unit50under the diagnostic address with the aid of a communication infrastructure48and communicates updating request24to hypervisor16. Hypervisor16transfers machine code20from read-only memory14into random-access memory12, starts the virtual machine and executes (26) a boot manager28of virtual machine18. Boot manager28receives an up-to-date machine code22under the diagnostic address of virtual machine18and exchanges machine code20in read-only memory14at least partially for up-to-date machine code20. Finally, boot manager28restarts (30) virtual machine18.

FIG. 2illustrates a detailed scenario in the context of updating a control unit (electronic control unit, ECU) without its guest systems being taken out of operation.

While a conventional control unit52on its hardware platform42executes only one software44with a single diagnostic address A, in the case of virtualized control unit40, a hypervisor16(virtual machine monitor, VMM) operates a first virtual machine18under diagnostic address B and a second virtual machine32under diagnostic address C on one joint physical machine38. Both first virtual machine18and second virtual machine32are therefore capable of conducting diagnostic communication. Diagnostic address B or diagnostic address C represents both virtual machine18,32operated under it as well as hypervisor16itself.

A diagnostic updating request24is received under diagnostic address B from an external unit50, e.g., a diagnostic tester. First virtual machine18in question communicates this to hypervisor16.

Addressed first virtual machine18requests of hypervisor16the transfer and execution of machine code20of hypervisor16and first virtual machine18from random-access memory (RAM)12. If the configuration of hypervisor16allows it, hypervisor16transfers relevant machine code20into random-access memory12, and continues26the execution from there. In this context, as a rule, first virtual machine18and second virtual machine32are only able to be updated within area boundaries36of their allocated resources such as storage space, devices and number of processor cores.

If area boundaries36are meant to be adapted, hypervisor16is therefore to be updated first.

First virtual machine18now restarts and executes a boot manager28(bootstrap loader, boot loader) from random-access memory12. Boot manager28is reachable under diagnostic address B of first virtual machine18.

Boot manager28thereupon receives further instructions and current machine code22in order to carry out the update by way of a diagnostic communication to diagnostic address B of first virtual machine18in question. Boot manager28selectively updates first virtual machine18or hypervisor16as a function of updating request24.

Finally, boot manager28restarts first virtual machine18(26). The customary boot sequence now continues and restarts first virtual machine18(30). If hypervisor16was updated, first virtual machine18requests a complete system restart from hypervisor16. In any case, new functionality first becomes active after either the restart of hypervisor16or of the system.