CN103116570A

CN103116570A - 具有动态可重构监督程序节点的分布式计算架构

Info

Publication number: CN103116570A
Application number: CN2012103323852A
Authority: CN
Inventors: T.E.福尔曼; S.梅农; L.E.佩鲁斯基
Original assignee: GM Global Technology Operations LLC
Current assignee: GM Global Technology Operations LLC
Priority date: 2011-09-09
Filing date: 2012-09-10
Publication date: 2013-05-22
Anticipated expiration: 2032-09-10
Also published as: DE102012215384A1; US20130067465A1; CN103116570B; US8621463B2

Abstract

一种动态重构分布式计算架构的方法，所述分布式计算架构具有多个处理节点，其中每一个处理节点以相应的多个虚拟机为主机，所述方法包括检测第一处理节点上的故障条件、评估通过第一处理节点上的每一个相应虚拟机执行的软件功能的关键性、和如果至少一个虚拟机被评估为处于临界关键性等级以上，则重新分配第一处理节点上的多个虚拟机中的至少一个给第二处理节点。

Description

具有动态可重构监督程序节点的分布式计算架构

技术领域

本发明大致涉及分布式计算架构，其包括动态可重构的监督程序节点（hypervisor node）。

背景技术

基于软件的电子控制系统越来越多地被用在汽车工业以控制影响车辆的运动和动态稳定性的自主驾驶特征和主动安全性。因为在软件中实施的对促动器的控制智能、自动决策进行、和控制权力的等级持续增加，这些控制系统变得越来越关键。这些控制系统的软件、硬件和系统架构因此必须是能容错的，且在一些情况下甚至是故障后保持工作的。这要求冗余软件、计算硬件、传感器、促动器和网络通信部件必须被设计到系统中，从而如果一个部件发生故障，则另一部件是可用的以继续提供安全等级的功能，无论是在全性能模式或下降性能模式中。

冗余硬件部件必须被静态地设计到系统中，因为并不易于将新的硬件(传感器，促动器，计算机，通信链路，配线束)添加到处于行驶循环的中间的车辆中。为此，车辆的各种控制系统可以在多个硬件装置上分布，其中单个硬件故障不会削弱整个车辆操作。另一方面，冗余软件部件可以静态地或动态地分配在系统中。

发明内容

一种动态重构分布式计算架构的方法，所述分布式计算架构具有多个处理节点，其中每一个处理节点以相应的多个虚拟机为主机，所述方法包括检测第一处理节点上的故障条件、评估通过第一处理节点上的每一个相应虚拟机执行的软件功能的关键性、和如果至少一个虚拟机被评估为处于临界关键性等级之上，则重新分配第一处理节点上的多个虚拟机中的至少一个给第二处理节点。多个处理节点中的每一个可以是不同的计算装置，每一个计算装置包括物理计算硬件和软件。

重新分配所述至少一个虚拟机可以包括产生监督程序配置文件和将监督程序配置文件传输到第二处理节点。监督程序配置文件可指示第二处理节点上的监督程序来分派物理计算硬件的使用给所述至少一个重新分配的虚拟机。物理计算硬件可以包括，例如，数字处理装置和易失和/或非易失存储器、以及模拟和/或数字输入/输出(I/O)电路、和/或网络通信电路。另外，监督程序配置文件指示第二处理节点上的监督程序，以将物理计算硬件的分配减少至多个虚拟机中的至少一个。

在一种配置中，物理计算硬件的使用根据时分方案、优先级方案、或固定映射方案分配。软件功能的关键性可以通过根据诸如ISO26262-9:2011中所规定的汽车软件完整性对软件功能分类而被评估。

另外，具有动态可重构处理节点的分布式计算架构可以包括主管节点（所述主管节点包括物理计算硬件和可执行软件），和与主管节点在数据网络上通信的第一处理节点和第二处理节点。第一和第二处理节点中的每一个可以分别包括物理计算硬件、监督程序、和多个虚拟机。监督程序可以配置为将物理计算硬件的使用分派给多个虚拟机。另外，重构管理器可以运转在主管节点上。

重构管理器可以配置为检测第一处理节点上的故障条件、评估通过第一处理节点上的每一个相应虚拟机执行的软件功能的关键性、和如果至少一个虚拟机被评估为处于临界关键性等级之上，则重新分配第一处理节点上多个虚拟机中的至少一个给第二处理节点。

在一种构造中，重构管理器进一步配置为提供监督程序配置文件给第二处理节点，所述监督程序配置文件可以指示第二处理节点上的监督程序分派物理计算硬件的使用给所述至少一个重新分配的虚拟机。另外，监督程序配置文件可以指示第二处理节点上的监督程序，以将物理计算硬件的分配减少至多个虚拟机中至少一个。

物理计算硬件可以根据时分方案、优先级方案、或固定映射方案分派给处理节点上的多个虚拟机。而且，重构管理器可以配置为通过根据ISO26262-9:2011中规定的汽车软件完整性等级对软件功能分类而评估软件功能的关键性。

本发明的上述特征和优势以及其他特征和优势将从以下结合附图时用于实施本发明的最佳模式的详细描述显而易见。

附图说明

图1是分布式计算架构的示意图，该分布式计算架构包括多个不同的计算装置。

图2是包括多个虚拟机的处理节点的示意图。

图3是图1的分布式计算架构的示意图，其中虚拟机从故障的计算装置被重新分配给运行的计算装置。

图4是用于动态重构分布式计算架构的方法的流程图，所述分布式计算架构具有多个处理节点。

图5是示出在重构之前和之后处理器分配的处理器分配图。

图6是示出在重构之前和之后存储器资源分配的存储器映像图。

图7是分布式计算架构的示意图，所述分布式计算架构包括多个不同计算装置，其中处理节点具有储存在其中的多个休眠虚拟机。

具体实施方式

参见附图，其中在各附图中相同的附图标记用于表示相同的部件，图1示意性地示出了分布式计算架构10，所述分布式计算架构10包括在数据网络24上通信的多个不同的计算装置20。如将在下面讨论的，每一个计算装置20可以包括计算硬件和可执行软件和/或固件(本文仅称为“软件”)，所述计算硬件和可执行软件和/或固件可以允许装置执行一个或多个具体任务。架构10可以适于控制更广泛的系统或与更广泛的系统接口，所述更广泛的系统例如汽车，其中存在许多不同的子系统，每一个子系统均受到电子控制或监视。

在架构10内，多个计算装置20可以配置为处理节点21、22、23，且至少一个计算装置20可以配置为操作为主管节点25。通常，处理节点可以包括应用软件，所述应用软件配置为与更广泛的系统接口且执行一个或多个控制或监视功能和/或诊断程序。相反地，主管节点可以查看和/或管理驻于各个处理节点上的控制/监视程序的性能、行为或执行。另外，主管节点可以检测处理节点中的意外行为或故障，可以在节点21、22、23上分配或重新分配资源，和/或可以调度（orchestrate）或监管网络24上的通信。

每一个处理节点21、22、23可以以一个或多个虚拟机为主机，所述虚拟机可以用于将各控制/监视例程彼此隔离(即，每一个虚拟机可以配置为执行一个或多个相关程序)。如在本文使用的，虚拟机是计算机器(即计算机)的软件实施，其执行很像独立物理机器的程序或控制算法。例如，处理节点21可以以虚拟机31和32为主机，处理节点22可以以虚拟机33和34为主机，处理节点23可以以虚拟机35和36为主机。每一个节点21、22、23可以包括相应监督程序（hypervisor）30或虚拟机管理器，其可以根据预定计划或调度在虚拟机之间分派下层物理机器资源。该类型的虚拟化经常被称为硬件虚拟化，因为监督程序30在虚拟机的操作环境和物理硬件之间运行。

图2进一步示出了处理节点21的结构。如所示的，处理节点21可以实施为计算硬件40和软件42的组合。计算硬件40可以包括各种硬件资源，例如一个或多个数字处理装置44、易失和/或非易失存储器46、模拟和/或数字输入/输出(I/O)电路48、和/或网络通信电路50。例如，一个或多个数字处理装置44可以每一个包括一个或多个微处理器、中央处理单元(CPU)或数字信号处理器(DSP)，或其他集成的处理装置；存储器46可以包括只读存储器（ROM）、随机访问存储器（RAM）、闪存存储器、和/或电可擦可编程只读存储器(EEPROM)；I/O电路48可以包括高速时钟、模拟-数字（A/D）电路、和数字-模拟（D/A）电路、和信号调制装置和/或缓冲电子设备；网络通信电路50可以包括一个或多个网络接口卡、控制器、和/或无线发射器。

软件42可以在计算硬件40上运行/通过计算硬件40运行，且可以在它的最基本级包括监督程序30，所述监督程序30可以将计算硬件40的使用分派到各虚拟机31、32。分派的方式可以由与监督程序30一起提供的配置文件52来控制。例如，配置文件52可以指定计算硬件40根据时分方案、优先级方案、或固定映射方案来分派。

时分分派方案可以指定，例如，在10ms时间窗口上，分给虚拟机31有6ms的处理时间(从数字处理装置44)且分给虚拟机32有4ms。在基于优先级的分派方案中，处理器使用量(或对其他计算资源的占用）可以根据固定的优先级调度而被支配，这可以大致反映正在由各虚拟机31、32执行的任务的关键性。最后，在固定映射或其他基于映射的分派方案中，一些资源(例如存储器或通信通道)可以静态地支配给仅具体虚拟机。使用任何这些方案，计算硬件40可以针对每一个虚拟机31、32虚拟化为虚拟计算硬件54、56的独立集（independent set）。

在硬件虚拟化环境中，软件42内定义的每一个虚拟机31、32可以包括其自身的独立操作系统58、59和应用软件60、62，所述应用软件60、62可以执行机器的相应软件功能。在实施例中，如果应用软件被嵌入和/或配置为与计算硬件40直接接口(经由虚拟的计算硬件)，则用于具体虚拟机的操作系统58可以被省略。如可理解的，应用软件60、62可以实施一个或多个应用级程序，所述程序可以执行控制、监视、和/或数据记录功能。在汽车的情况下，具体应用的例子可以包括转向控制、速度传感/控制、油门控制、制动控制、发动机诊断管理、冷却剂温度监视、变速器管理、挡风玻璃擦拭控制、和/或其他辅助系统控制。

再次参见图1，如上所述，一个计算装置20可以配置为主管节点25，且可以在数据网络24上与各处理节点21、22、23中的每一个通信。类似于关于图2所述的处理节点21，主管节点25可以包括计算硬件和在硬件上/通过硬件运行的应用软件两者。在实施例中，主管节点25上运转的应用软件可以包括重构管理器70，所述重构管理器70可以配置为监视每一个处理器节点21、22、23的运转状态，且所述应用软件在硬件失效或其他不可恢复的故障事件中重新分配一个或多个虚拟机给其他计算装置。以该方式，重构管理器70可以动态地建立系统冗余，允许关键系统/应用继续运转，甚至在给定计算装置20的部分或全部硬件失效的事件中也是如此。

重构管理器70的运转在图3中示意性地示出且关于图4的方法80描述。如图3中提供的假设情形所示，在处理节点23上已经发生了故障，这使得节点23暂时地或永久地不能运转。由于节点23的不能运转性，在虚拟机35、36上运转的任何应用已经被挂起或冻结。重构管理器70可以通过在步骤90检测该节点23上的故障条件的存在而开始。步骤90的故障检测可以例如通过接受故障代码而发生，诸如由故障检测电路/例程而在节点23上直接地产生(例如看门狗电路（watchdog circuit）)，或可以通过节点23的超时或失效以确认请求而发生，或通过分析节点的性能(即通过将实际的数据/行为与期望的数据/行为比较)而发生，或通过一些其他故障检测手段而发生。

一旦在步骤90重构管理器70已经检测到故障，在步骤92它可以识别哪些软件功能或具体应用软件可以被故障影响。该识别可以通过首先识别故障的特性，随后识别可以被故障牵连和/或连累的硬件和/或软件，且最后通过识别可以依赖于受牵连的硬件和/或软件的任何应用软件而执行。

在步骤92中识别了受影响的应用软件之后，由受影响的软件执行的软件功能(例如，控制、监视、和/或数据记录功能)可以在步骤94中被评价，以识别它们的关键性等级（criticality level），且相应地，识别它们被重新分配到另一计算节点的需要。在实施例中，每一个软件功能可以被预先指定关键性等级或对总系统的相对重要性。这些预先指定的等级可以存储在与主管节点25相关联的存储装置或数据库96中，且可以在故障事件中容易访问。如果软件功能被视为是“关键的”或“重要的”(即如果虚拟机被评价为处于临界关键性等级之上)，则重构管理器70可以标记执行该软件功能的虚拟机，用于重新分配给另一计算装置。在汽车的情况下，关键性或重要性等级可以是基于功能安全性考虑的，诸如在IEC 61508或ISO 26262-9:2011中规定的。例如，ISO26262-9:2011定义了四个汽车安全完整性等级（AutomotiveSafety Integrity Level），其根据情况的潜在的暴露/频率、系统12在没有特定功能的情况下的可控制性、和可能的损坏的严重性或影响而对功能安全性进行分类。

一旦在步骤94中虚拟机被标记用于重新分配给另一计算装置，则重构管理器70必须随后确定哪个剩余的处理节点最适于接收虚拟机。例如，重构管理器70可以首先检查系统以确定任何处理节点是否具有可用的处理容量或未分配的存储器。如果没有空间存在，则重构管理器70可以随后识别工作节点上的虚拟机，所述工作节点上的虚拟机具有比要被重新分配的虚拟机更低的关键性或重要性。重构管理器70可以随后决定是否减少或消除对较低关键性虚拟机的硬件资源的分配，以适应重新分配的虚拟机。在步骤98中的所述另一方式为，重构管理器70可以分析整个系统，并决定如何最好地分配可用的、工作的硬件资源给最关键或最高优先级的虚拟机。在实施例中，可用资源的分配/评估可以鉴于系统硬件分配数据库100进行，所述系统硬件分配数据库100存储在与主管节点25相关联的存储器中，且通过重构管理器70可访问。该数据库100可以提供系统架构内的所有硬件的容易访问的清单，和硬件目前在各虚拟机之间如何分配。

一旦在步骤94中需要重新分配的关键功能被识别，和在步骤98中可用的、工作的硬件资源被识别和评估，则在步骤102中重构管理器70可以产生新的/改变的监督程序配置文件152用于一个或多个计算装置，且在步骤104中可以将它们传输到装置。新的配置文件152可以遵从预定的约束，诸如I/O通道、通信通道、或处理线程的可用性，这可以在与重构管理器70相关联的存储器106中指定。

再次参见图3，且类似于图1，架构10可以包括三个处理节点21、22、23。处理节点21可以初始地以虚拟机31和32为主机，处理节点22可以以虚拟机33和34为主机，处理节点23可以以虚拟机35和36为主机。重构管理器70可以在主管节点25上运转，且可以在数据网络24上与处理节点21、22、23通信。

在实施例中，重构管理器70可以检测节点23上的故障，且随后评估由现在的未运转虚拟机35和36执行的软件功能的关键性。在虚拟机35被视为“关键”且有必要被重新分配的例子中，重构管理器70可以随后确定最合适的功能节点(例如，节点21、22)，以新的虚拟机135为主机(所述虚拟机135可以是虚拟机35的副本或缩简（pared down）版本）。在功能节点21、22的可用硬件资源的评估之后，重构管理器70可以通过提供具有新的配置文件152的相应监督程序30而重新分配虚拟机35给节点21。新的配置文件152可以分派计算硬件资源给新的虚拟机135，例如，通过减少对虚拟机31和32的相应分派，或通过完全地消除对最低优先级虚拟机(例如虚拟机32)的分派。

图5和6示出了重新分配方案的一个可行实施例，该重新分配方案可以通过新的/改变的监督程序配置文件152实施。图5大致示出了两个处理时间分配图200、202，诸如用于数字处理装置44，其中图200表示初始处理器分配，图202示出了重构的分配。每一个图200、202被表示在固定量的时间210上。在第一图200中，提供虚拟机31第一量的处理时间231，且提供虚拟机32其余的处理时间232。但是，不提供虚拟机135任何时间235(或可忽略量的时间)。在处理器重新分配之后(即，收到新的配置文件152)，用于虚拟机31的处理时间231可以保持不变，但是，用于虚拟机32的处理时间232可以被减少和通过将处理时间235分配给虚拟机135而被有效地替代。

图6大致示出了两个存储器分配映射300、302，所述存储器分配映射300、302分别表示重新分配前和分配后。如所示的，在计算装置20接收新的配置文件152之前，第一映射300在相应虚拟机31和32之间提供大体相等的存储器分配331、332。在重新分配之后，存储器可以根据第二映射302来分配，该第二映射302将存储器块332(来自第一映射300)重新分配给虚拟机135(如存储器块335)。

尽管之前的描述主要用于通过用新的监督程序配置文件152来更新监督程序配置文件52而建立虚拟机冗余性(即，重新分派现有的硬件资源的使用)，但是其不特别解决新的虚拟机135从哪里来的问题。如可理解的且关于图2描述的，虚拟机可以包括经编译的应用软件和操作系统两者。该软件可以在被分配有硬件资源的共享之前优选定位为对于相应处理节点是本地的。因此，在诸如图7中示意性地示出的实施例中，一个或多个其他虚拟机的休眠副本可以被包括在每一个计算装置上。该配置可以通过消除在通信网络24上转移虚拟机本身的需要而提供迅速的重构速度。例如，处理节点21可以包括休眠虚拟机133和135，所述休眠虚拟机133和135可以分别是虚拟机33和35的副本。同样，处理节点22可以包括休眠虚拟机132和136(分别是虚拟机32和36的副本)，处理节点23可以包括休眠虚拟机131和134(分别是虚拟机31和34的副本)。休眠副本可以，例如，是存在于处于经编译和可运转的、或接近可运转状态的软件42内的虚拟机。但是，其可以被认为是“休眠的”，这是因为其可以被监督程序30分配为没有处理时间、没有存储器、没有I/O访问和/或没有通信通道，由此将其置于挂起/休眠状态。

在收到新的/改变的配置文件152时，监督程序30可以通过对其分配计算硬件资源40的共享而激活，或启动之前休眠的虚拟机。在实施例中，新的/改变的配置文件152可以仅是预先存在的配置文件52的修改，其用于重新分配各物理硬件资源。通过包括处于休眠状态下的一个或多个冗余虚拟机，重构可以在故障检测时迅速地执行而不需要编译新的软件或转移新的软件到处理节点。

在实施例中，每一个虚拟机31-36的冗余副本可以架构10中某处在至少一个其他处理节点上处于休眠状态(诸如大致在图7示出的)。在另一实施例中，每一个节点可以包括系统内的每个虚拟机的全部副本。各虚拟机的预先加载、冗余副本的位置可以被用作关键虚拟机的重新分配的约束。

尽管已经对执行本发明的较佳模式进行了详尽的描述，但是本发明所涉及的领域的技术人员将认识到在所附的权利要求的范围内的用来实施本发明的各种替换设计和实施例。意图是在上面描述中所包含的和在附图中所示的所有内容应被理解为仅是说明性的而不是限制性的。

Claims

1.一种动态重构分布式计算架构的方法，所述分布式计算架构具有多个处理节点，所述多个处理节点包括第一处理节点和第二处理节点，每一个处理节点以相应的多个虚拟机为主机，所述方法包括:

检测第一处理节点上的故障条件；

评估由第一处理节点上的每一个相应虚拟机执行的软件功能的关键性；和

如果至少一个虚拟机被评估为处于临界关键性等级以上，则重新分配第一处理节点上的多个虚拟机中的至少一个给第二处理节点。

2.如权利要求1所述的方法，其中重新分配所述多个虚拟机中的所述至少一个包括产生监督程序配置文件和将监督程序配置文件传输到第二处理节点。

3.如权利要求2所述的方法，其中监督程序配置文件指示第二处理节点上的监督程序将物理计算硬件的使用分派给所述至少一个重新分配的虚拟机。

4.如权利要求3所述的方法，其中物理计算硬件包括数字处理装置和存储器。

5.如权利要求3所述的方法，其中监督程序配置文件指示第二处理节点上的监督程序将物理计算硬件的分配减少至多个虚拟机中至少一个。

6.如权利要求3所述的方法，其中物理计算硬件的使用根据时分方案、优先级方案或固定映射方案被分派。

7.如权利要求1所述的方法，其中多个处理节点中的每一个是不同的计算装置，每一个计算装置包括物理计算硬件和软件。

8.如权利要求1所述的方法，其中评估软件功能的关键性包括根据ISO26262-9:2011中规定的汽车软件完整性等级而对软件功能分类。

9.如权利要求1所述的方法，其中第二处理节点的至少一个虚拟机处于休眠状态，休眠状态下的虚拟机是来自多个处理节点中另一个的虚拟机的副本。

10.一种具有动态可重构处理节点的分布式计算架构，所述架构包括:

主管节点，包括物理计算硬件和可执行软件；

第一处理节点和第二处理节点，所述第一处理节点和第二处理节点在数据网络上与主管节点通信，第一和第二处理节点中的每一个分别包括物理计算硬件、监督程序和多个虚拟机，监督程序被配置为将物理计算硬件的使用分派给多个虚拟机；和

重构管理器，在主管节点上运转且配置为:

检测第一处理节点上的故障条件；

评估通过第一处理节点上的每一个相应虚拟机执行的软件功能；和

如果至少一个虚拟机被评估为处于临界关键性等级以上，则重新分配第一处理节点上多个虚拟机中的至少一个给第二处理节点。