用于实例化至少一个执行环境的方法

技术领域

本发明涉及一种用于实例化至少一个执行环境的方法以及一种用于执行该方法的组件。

背景技术

执行环境也称为运行时环境，其描述了特定运行时系统的在计算机程序运行时可用且已确定的前提条件。这由编程语言的基本要素(例如语言构造的行为)和其他功能定义。执行环境还包括执行时间库、标准库、编程接口、运行时变量以及硬件和软件部件和操作系统功能。

为了降低成本、减轻重量并实现创新的新功能，在汽车领域中越来越多地使用硬件资源虚拟化技术。这些技术(例如呈虚拟机管理程序或操作系统容器的形式)可以使得将不同的执行环境(例如操作系统实例)整合在诸如汽车ECU(ECU：电子控制单元)的通用硬件上。虚拟化是新的E/E车辆概念(E/E：电气/电子)的核心组成部分，例如车辆计算机。

在此，执行环境的特征在于满足对性能、软件质量、功能行为、工具支持或者可更新性或可升级性的要求时的特定质量。在实例化的时间点，为不同的执行环境分配硬件资源，例如CPU或易失性存储器。根据分离程度和硬件支持为执行环境提供硬件资源，就像执行环境分别是资源的独占用户一样。在硬件中没有直接虚拟化支持的子系统中，通常借助于轻量级仲裁层进行并行硬件访问。

出于功能安全和质量保证的原因，在至今为止具有和不具有驾驶安全目标的系统中，执行环境的资源分配和实例化大多是静态进行的。在此，虚拟化技术使用固定设置的配置，并在整个系统启动时启动执行环境。在执行期间，动态性减少为具有抢占功能、即排挤性的那些硬件资源。由此，如果在所配置的执行环境内没有需求，则可以将每单位时间为该执行环境配置的CPU使用时间附加给另一执行环境。对于其他资源(例如易失性存储器)，这种抢占不容易实现。

在已知方法中，特别是探讨了具有不同安全级别的域的分离，其中配置在开始时是确定的，并且显然无法在运行时改变。

发明内容

在这种背景下，提出了一种用于在汽车领域中的控制单元上实例化至少一个执行环境的方法和一种用于执行该方法的组件。此外，还提出了一种计算机程序以及机器可读存储介质。

所提出的方法用于在汽车领域的控制单元上实例化至少一个执行环境，其中由执行控件动态地选择用于满足至少一个执行环境的要求的资源，并且由虚拟化系统将这些资源分配给各个执行环境。

基本动态性在于在实例化的特定时间点且在执行环境的运行时期间根据控制单元的运行环境以及对执行环境的性能和功能范围的具体要求来分配资源。

在执行时，执行控件访问虚拟化系统中的控件接口和最小配置。这可以使得安全且快速地访问所需数据。

还可进一步改变至少一个执行环境中的一个执行环境的配置，以便对执行环境的经改变的要求或需求做出响应。

在实例化之后，可以在控制单元中运行设置了执行环境的计算机程序。

此外，可以由控制单元外部的激励来触发或影响该方法。由此，可以对发生在控制单元之外并可能还发生在设置有控制单元的机动车之外的事件做出适当的响应。

在另一实施方式中规定，执行控件在至少一个执行环境中的一个执行环境中实施。

实例控件可以用于至少从至少一个执行环境中的一个执行环境收集需求，以便可以立即或在之后的某个时间点考虑这些需求。

利用所提出的方法，可以对系统中所存在的不同执行环境的硬件资源分配进行动态配置，并且可以在系统运行时对执行环境的实例化和终止进行功能控制。

由此，该方法使得可以基于系统内部事件和系统外部事件来实现分配和实例化策略。该方法特别是使得汽车ECU可以在不同的操作模式中运行，其中可以激活不同或不同配置的执行环境。在此，根据所述方法提出的机制还可以在运行时切换操作模式。

实例化通常指特定类的对象的创建，在这种情况下指创建执行环境。分配通常可理解为是指为某个单元(在这种情况下是为执行环境)选择资源。汽车领域是指该方法在机动车中的应用。

域是执行环境被设置用于实现的要求的总和。执行环境特别是指为满足上述要求而设置的技术实现。

此外，所提出的机制还使得可以在关于各个执行环境的执行状态的配置或决策与虚拟化技术以及为执行环境设置的可用硬件资源限制的实施或强制执行之间进行功能分离。由此，这与已知方法相比特别是在对功能安全有很高要求的系统中还带来了工艺和开发优势。

所提出的方法至少在某些实施方式中具有一系列优点：

执行环境的实例化可以推迟到系统启动之后的某个时间点，以便由此提高系统的启动速度。在此，至今为止的静态解决方案显示出在系统启动期间的所谓的“抢滩期行为”，这导致了系统中对时间要求严格的功能的可用性出现延迟。就此而言，“抢滩期行为”意味着：子部件的启动占用了所有CPU内存资源，使得其他子部件仅能够非常延迟地启动。所提出的以时间或事件控制方式协调不同域中子部件的启动的可能性改善了已知方法。

执行环境的实例化可关联到特定事件。例如，设备诊断功能的激活可能使得实例化具有诊断服务的执行环境。当同时关闭在诊断模式中不需要的执行环境时，一方面将资源释放给另一执行环境，另一方面通过减少在相应操作模式下可访问的接口来提高系统的网络安全性。

执行环境的终止可关联到特定事件。由此，例如设备诊断功能的激活可能使得停用具有驾驶功能的执行环境，以避免干扰。这使得复杂度降低，并且有利于在运行时条件下整个系统的功能保障，而这是已知方法无法实现的。

在无需重启设备的情况下可通过执行环境的有针对性的实例化或终止来更新执行环境，例如通过域的所谓的OTA更新(OTA：空中下载)、关闭旧域、验证更新并且启动更新后的域。

随着各个控制单元上功能的整合不断增强，由于不必关闭整个系统，而仅需关闭所更新的执行环境，因此可以提高整个系统的可用性。由此，在车辆中即使在更新之后重新启动执行环境时也保留更少的功能范围。

在执行环境发生故障的情况下，可以通过以下方式实施恢复机制：1.在进行域的OTA更新之后；2.关闭旧域；3.验证更新后的执行环境，结果是有故障；4.启动旧域。还可以在通过执行环境所实现的应用级通过另一检验机制(例如功能检验)来触发恢复。恢复的实施以类似方式进行。

这可能意味着执行环境的功能被所激活的替代执行环境替换，或者被替换为待重新实例化的映像。这提高了可用性方面的功能安全性和鲁棒性方面的质量。可以说，替代执行环境总是可用的，这在目标执行环境出现故障时构成后备解决方案。

如果在机制策略中通过配置知识可排除竞争性执行环境被同时激活，则无抢占力的硬件也可被多次分配。由此实现了对硬件资源的更有效利用，并且减少了仲裁层的数量。

通过终止或停用非关键执行环境从而重新进行分配，可以在短时间内提高单个执行实例的性能。

通过可以将关键功能(例如安全相关功能的激活和停用)与系统的非安全相关部分的控制分开，所提出的方法允许在具有混合功能安全级别的系统中使用。

该方法使得可在具有不同安全要求的系统中使用，因为可以通过相应的访问控制系统在安全技术上确保将执行环境限制为单个系统实体的能力。

所介绍的组件用于执行所述方法，并且例如被设置在控制单元中，特别是机动车的控制单元中，或被设计为控制单元。此外，该组件可以硬件和/或软件形式实现。

本发明的其他优点和设计方案从说明书和附图中得出。

应理解的是，上述特征和以下待说明的特征不仅可以相应指定的组合形式使用，而且可以其他组合形式或单独使用，而不会脱离本发明的范围。

附图说明

图1示出了被设置为执行所述方法的控制单元。

图2以流程图示出了所述方法的一个实施方式。

在附图中借助实施例示意性地示出了本发明，并且下面参考附图加以详细说明。

具体实施方式

图1以示意图示出了控制单元，其被设置用于执行在此提出的方法，并且总体上以附图标记10表示。该图示示出了第一执行环境20、第二执行环境22、第三执行环境24、虚拟化系统30(在该情况下为虚拟机管理程序)以及诸如CPU、RAM等的硬件资源32。

激励提供器34可以从外部预设用于激发或触发动作的激励36。功率开关38可以实现接通。

在第一执行环境20中设置有第一激励提供器40和执行控件42。在第二执行环境22中设置有第二激励提供器50和第一实例控件52。在第三执行环境24中设置有第二实例控件60。在虚拟化系统30中存储有控制接口70和最小配置72。第一执行环境42中的第一执行控件42访问控件接口70和最小配置72。

所提出的方法的重要元素是控制单元10中的以下称为执行控件42的实体及其在整个系统中的集成，包括诸如实例控件52或60的扩展。

根据该方法，在固有逻辑方面不做任何限制，执行控件42要么具有其自身配置的状态机，要么遵循更高级别的逻辑或外部控制。

由此，控制单元10包括通过虚拟化系统30(例如虚拟机管理程序)控制的多个执行环境20、22、24。在此，虚拟化系统30还可以在空间上分布在控制单元10的多个硬件组件上，例如具有微处理器的SoC(片上系统、单芯片系统)和专用微控制器。虚拟化系统30可以将硬件资源32分配给各个执行环境20、22、24，并且实例化和终止执行环境20、22、24。

只要将控制单元10与稳定的电流源连接，必要时可为此进行扩展，例如唤醒CAN或控制单元10的类似全局控制，从而启动虚拟化系统30。虚拟化系统30使用最小配置72，该最小配置72可以被存储在控制单元10可访问的存储区域中。该最小配置72可以在控制单元设计时创建一次，也可以通过执行控件42的机制进行管理和更新。后者为扩展。

虚拟化系统30提供控制接口70，执行控件42可以通过控制接口70从虚拟化系统30请求以下功能：

1.实例化或终止执行环境20、22或24，

2.(扩展1)更改执行环境20、22或24的配置，

3.(扩展2)添加或删除执行环境配置。

虚拟化系统30可以预设对执行环境20、22、24的配置和控制的限制。由此使得例如通过执行控件42进行的控制可限于非安全相关的功能。这使得执行控件42的开发可具有更少的安全过程要求。

在所示的实施方式中，执行控件42本身在执行环境、即第一执行环境20中执行。该第一执行环境20本身可以是最小配置72的一部分。作为替代可行的是，如果控制接口70以相应的方式可被访问，则执行控件42本身可以在虚拟化系统30中执行，或者执行控件42也可以在系统外部执行。执行控件42也可以分解为多个部件，控制逻辑可以分布在不同执行环境20、22、24中的不同进程中或者甚至分布在不同处理器上，例如用于控制执行环境20、22、24的部件分布在微处理器上并且用于控制的部件分布在微控制器上。另外，执行控件42可以分等级聚合，使得执行控件42的各个部分仅在包含该部分的执行环境20、22或24被执行控件42的更高实例激活时才变为激活状态。

执行控件42从不同的执行环境20、22、24中收集激励，例如关于操作模式、关于错误、关于本地应用的请求。也可使用外部激励，例如关于车辆起动的信号、端子15处的点火信号。执行控件42使用固定或可配置的逻辑，以便从激励36导出执行环境20、22、24的所期望的目标状态或目标配置。然后通过控制接口70被虚拟化系统30请求并且相应地被执行。

作为扩展，执行控件42也可具有实例控件。实例控件在执行环境内工作，并与执行控件42在功能上连接。实例控件在这种情况下为第一实例控件52和第二实例控件60，其可用于收集执行环境20、22、24的需求，例如是否需要更多的CPU时间来满足执行环境的本地目标。实例控件52或60也可以用于检测在执行控件42中触发错误响应的本地错误。在实例控件52或60与执行控件42之间的连接在实例化时动态建立。如果在执行环境内必须实施有序的停用、关闭，则实例控件52或60是必需的。

另外，与执行控件42相比，控制接口70呈现了虚拟化系统30的抽象，并且实例控件52或60呈现了执行环境20、22或24的抽象。抽象是指接口在执行控件42的方向上是稳定的，并且对相应虚拟化系统30或操作系统的适配在控制接口70或实例控件52或60中具体地进行。

图2在流程图中以极为简化的方式示出了所述方法的一个可能的实施方式。在第一步骤80中进行执行环境的资源的选择、即分配，这通常由执行控件、软件或计算机程序执行。在随后的步骤82中进行所选资源的保留或分配，这由诸如虚拟机管理程序的虚拟化系统、即硬件和软件来执行。然后在最后的步骤84中进行实际的执行。