更新在超级管理程序下运行的虚拟机的方法和设备与流程

本发明涉及一种用于更新在带有随机存取存储器和只读存储器的物理机器上在超级管理程序(Hypervisor)下运行的虚拟机的方法。此外，本发明还涉及一种相对应的设备、一种相对应的计算机程序以及一种相对应的存储介质。

背景技术：

公知的汽车控制设备通常具有用于进行车载诊断(On-Board-Diagnose)的能力。典型地，所提供的诊断在此涉及控制设备本身、其功能性和软件更新。例如可以借助极其不同的车辆通信网络、如CAN、Flexray或者以太网以及相应的诊断协议、如OBD来访问通用的(gattungsmaessig)控制设备的这些能力。为了在控制设备与外部诊断工具之间建立诊断通信连接，这样的控制设备具有诊断地址。在控制设备之内的唯一的软件系统的情况下，所描述的能力被认为是现有技术。

但是，在虚拟化的控制设备中存在多个软件系统(所谓的客户系统(Gastsysteme))和超级管理程序的附加的软件组件。作为其结果，对于每个客户系统、硬件和超级管理程序需要关于状态信息的诊断能力。客户系统和超级管理程序最后必须被更新。

DE 19921845 A1描述了一种用于汽车的诊断测试设备，其中在汽车中设置可编程的、具有自诊断装置的控制设备，所述控制设备以程序控制的方式控制、监控汽车的发动机控制装置和其他系统、生成错误代码以及存储所述错误代码，并且所述控制设备可以经由汽车侧的诊断/检验插头与外部诊断测试仪连接。外部诊断测试仪被配备有程序识别设备和程序加载设备。借助程序识别设备询问并识别在所连接的控制设备中包含的程序版本。接着，当在汽车侧现存的并且通过诊断/检验插头识别的、在汽车的所连接的控制设备中存在的程序没有被存储在最新的且最近的版本中时，由诊断测试仪的程序加载设备将分别最近的版本加载到相对应的控制设备的程序存储器中。

技术实现要素：

本发明提供了按照独立权利要求所述的一种用于更新在带有随机存取存储器和只读存储器的物理机器上在超级管理程序下运行的虚拟机的方法、一种相对应的设备、一种相对应的计算机程序以及一种相对应的存储介质。

所建议的解决方案以如下认知为基础：虚拟化的系统具有比单个软件系统更多的可更新的组件。在这里是需要彼此独立的更新的多个客户系统和超级管理程序本身。

这种解决方案的优点在于，保持现有的基于诊断通信和诊断地址以及引导管理器(Bootmanager)的流程。这样，每个客户系统都记住它自己的诊断地址，并能够处理诊断通信。通信基础架构可以或者在多个客户系统之间被分享，或者只被保留给一个客户系统。

在此，特别有利的是本发明的确定的实施形式的更新处于运行中的生产环境(Produktivumgebung)的能力。这意味着，超级管理程序和虚拟机连同由其实施的应用程序在虚拟机或者超级管理程序就在那儿被更新期间可以正常地继续运转。

在此，所介绍的方案考虑到如下情况：大部分控制设备(在汽车技术中比方说要考虑到发动机和车身控制或者行驶动态调节)实施其直接来自内部闪存的机器代码。在这样的设备处在更新的范围内执行的快闪重新编程期间，通过应用在这里讨论的方法使得在重新编程期间可以实施应用程序代码成为可能。就此而言，这被证实为合乎目的的，因为同时的代码实施在传统做法的情况下几乎是不可能的。

通过在从属权利要求中举出的措施能够实现在独立权利要求中说明的基本思想的有利的扩展方案和改进方案。这样可以设置，客户系统在被提高的授权级别(Berechtigungsstufe)上运行，并代表如下超级管理程序接收到更新要求：该超级管理程序最后通过引导管理器或者通过该引导管理器起动的引导加载程序进行更新。因此，为了更新的目的，该超级管理程序仿佛被分配给一个客户系统。该超级管理程序以这种方式可以与这个确定的客户系统共同被更新。

按照变型方案可以设置，该客户系统自己确定可能的更新(Update)并且触发该可能的更新。相对应的实施形式被证实为尽可能地与每个诊断工具无关。

附图说明

本发明的实施例在附图中示出，并在以下描述中作更详细地被阐述。附图中：

图1示出了按照实施形式的方法的数据流图。

图2示意性地示出了按照第二实施形式的控制设备连同可能的通信伙伴和基础架构的方框图。

具体实施方式

图1将所建议的用于更新在带有随机存取存储器12和只读存储器14的物理机器38上在超级管理程序16下运行的虚拟机18的方法10的基本流程概括成根据尤顿/迪马克符号(Yourdon/DeMarco-Notation)的数据流图。超级管理程序16在单独的诊断地址下运行虚拟机18，其中只读存储器14存储超级管理程序16和虚拟机18的机器代码20。虚拟机18在该诊断地址下借助于通信基础架构48从外部设备50接收到更新要求24，并将该更新要求24通知给超级管理程序16。超级管理程序16把机器代码20从只读存储器14迁移到随机存取存储器12，起动该虚拟机，并实施(26)虚拟机18的引导管理器28。引导管理器28在该虚拟机18的诊断地址下接收到当前的机器代码22，并至少部分地用当前的机器代码22代替只读存储器14中的机器代码20。引导管理器28最后重新起动(30)虚拟机18。

图2在更新控制设备(电子控制单元，ECU(electronic control unit))的范围内用图说明更详细的情景，而不必使其客户系统停止使用。

在常规的控制设备52在其硬件平台42上只实施具有唯一的诊断地址A的软件44期间，在虚拟化的控制设备40的情况下，在共同的物理机器38上在诊断地址B下，超级管理程序16(虚拟机监控器，VMM(virtual machine monitor))在诊断地址B下运行第一虚拟机18，并且在诊断地址C下运行第二虚拟机32。因此，不仅该第一虚拟机18而且该第二虚拟机32都能够运行诊断通信。诊断地址B或者诊断地址C不仅体现在其下运行的虚拟机18、32，而且体现超级管理程序16本身。

从外部设备50(例如诊断测试仪)，诊断的更新要求24在诊断地址B下到达。该相关的第一虚拟机18将这通知给超级管理程序16。

被寻址的第一虚拟机18在超级管理程序16处要求传输和实施超级管理程序16和第一虚拟机18的来自随机存取存储器12(RAM(random-access memory))的机器代码20。当超级管理程序16的配置允许这一点时，该超级管理程序16把有关的机器代码20传输到随机存取存储器12中，并从那出发继续进行26该实施。在此，第一虚拟机18和第二虚拟机32在一般情况下可以只在其所分配的资源、如存储位置、设备和处理器内核的数目的范围界限(Bereichsgrenze)36之内被更新。因而，当应该适配该范围界限36时，首先要更新该超级管理程序16。

第一虚拟机18现在重新起动，并实施来自随机存取存储器12的引导管理器28(引导装入程序(bootstrap loader)，bootloader)。引导管理器28在第一虚拟机18的诊断地址B下是可达到的。

此后，引导管理器28接收到其他指令和当前的机器代码22，以便在向相关的第一虚拟机18的诊断地址B的诊断通信的过程中执行更新。根据该更新要求24，引导管理器28选择性地更新第一虚拟机18或者超级管理程序16。

最后，引导管理器28重新起动第一虚拟机18(26)。现在，平常的引导顺序继续，并重新起动(30)第一虚拟机18。如果超级管理程序16曾被更新，则第一虚拟机18在超级管理程序16处要求完整的系统重新起动。不管怎么样，新的功能性只有在或者重新起动超级管理程序16或者重新起动系统之后才成为在起作用的。