EB corbos Hypervisor: 推动 ECU 架构演进

1. 引言

汽车车控域的 ECU 架构正在历经变革。其中部分原因是通过整合 ECU 或可实现成本节约，但更重要的是，为确保自己的车辆在未来的汽车市场上保有竞争力，厂家必须为车辆赋予新的功能。

在本文中，我们将讨论 ECU 架构会如何演化，并评估转变后的环境会产生怎样的影响，然后深入探讨由这些变化带来的对软件架构的新要求。最后，我们将展示 EB corbos Hypervisor 如何支持这些未来的 ECU 架构。

2. 通过整合推动系统架构的演进

汽车 E/E 架构可分为三大类：分布式架构、域控架构和区域式架构。以下是对每一类架构的简要描述。

分布式架构是最成熟的一类架构。其系统功能通过分配到一个或多个专用 ECU 上的传感器、执行器和控制器来实现。ECU 之间的交互是有限的，从而限制了系统功能在系统层面和组织层面上的潜在协同效应。

图 1：分布式架构
OEM 厂商正逐步从分布式架构向域控架构过渡。域控架构的主要特点在于特定车控域的系统功能被分配到一个高性能计算平台（HPC），而该平台为其他域之间的通信提供了一个网关。域控架构的高性能是通过减少通信开销以及所运行的强大平台来实现的。

图2：域控架构
区域式架构的特点是将多个车控域整合到一个硬件平台上，利用以太网提供骨干网络，以实现与车辆传感器和执行器 ECU 的网关之间的高速/高带宽通信。通过整合车控域，便可利用它们之间的协同效应。例如，可以通过合并不同车控域的传感器数据来开发复杂的系统功能。

图 3：区域式架构
虽然不同 OEM 厂商的发展速度有所不同，但演进是大势所趋。因此，软件架构必须与时俱进，以支持未来的车辆 E/E 系统。Elektrobit 提供的许多解决方案正是由此而生。

3. 对 OEM 厂商和车控域的影响：一场革命！

车辆 E/E 架构的变化可能是一种演进，但在多数情况下，这种演化所带来的影响将在 OEM 厂商和一级供应商之间掀起一场革命。曾经需要在孤立的 ECU 中才能开发的系统功能如今能够共享一个通用平台，这给以往基本上独立的开发周期和开发环境带来了新的依赖关系。考虑到合并到一个平台上的软件的混合关键性以及越来越多地使用开源软件，诸如功能安全和信息安全这样的系统属性将呈现出新的维度。

意识到这一点后，OEM 厂商开始自行开发软件，以便掌握这些整合系统的复杂性。OEM 厂商必须平衡每一个系统功能和车控域对硬件、操作系统和中间件层的需求，从而实现协调的车辆 E/E 架构。

OEM 厂商承担着较高的风险。如果不能妥善协调整合车辆 E/E 系统的需求，可能会导致维护成本上涨，可靠性降低，甚至可能会由于车控域需求得不到满足而阻碍到量产。我们现在生产的最新车辆系统就面临着这样的问题。新推出的产品系列不能给用户带来惊喜，客户交付后软件更新太快已经成为常态。

因此，及时发现因开发环境发生变化而产生的高性能计算软件架构的新需求是至关重要的。

4. 对软件架构的影响：满足多种需求的压力

为了解人们对软件架构的新需求，我们有必要自上而下/自下而上检查一下整合系统各层，并评估其对不同元素的影响。整合车辆 E/E 系统的软件架构如下所示。

图4：整合 ECU 分层架构
自上而下从系统功能层开始，我们可以看出应用软件可能直接通过操作系统使用内存、CPU、IO 设备或文件系统等资源。应用软件也会依赖中间件解决方案，以便与对 HPC 平台本身而言的本地其他系统元素进行通信和交互，或者与车辆内部甚至外部的系统元素进行交互。

由于整合系统必须支持对软件服务需求大不相同的多种系统功能，因此其可能还须支持多个中间件框架。所以，操作系统层必须平衡不同中间件解决方案的需求，以免相互干扰。

对于硬件层，最新趋势表明新的 HPC 硬件平台将提供为曾在不同 ECU 上实现的用例定制的组件。例如，具有以下内核的 SoC：以锁步模式运行的实时 CPU 内核和以性能为中心的内核。汽车 SoC 平台实现的创新将加速计算基础设施的集中化，使系统架构师不得不重新思考经典分层软件架构中采用的方法是否恰当。

现代多核处理器的性能强大，足以同时托管不同的操作系统及其用户空间，这表明我们可以在同一处理器上同时托管整合车辆 E/E 架构的不同配置文件。反过来，这需要将不同的操作系统及其用户域无缝集成到处理器正在运行的软件中。

这绝非易事，因为公共基础设施和附加设备需在不同操作系统之间透明共享，而其他部分则需要映射到特定操作系统及其用户应用程序。

此外，必须确保集成软件栈的可扩展性和通用性足以适应未来的技术发展需要，例如在单个片上系统 (SoC) 上使用有多种架构和几十个 CPU 内核的异构众核系统。

根据自上而下/自下而上的整合车辆 E/E 架构分析，为使用硬件创新启用的新机制平衡应用软件和中间件的不同需求，操作系统层将承受巨大压力。

5. 虚拟化：功能强大且作用日益增大

在克服操作系统层面临的新挑战过程中，虚拟化功能强大，因为它既能将系统功能封装在自己的运行环境中，又能以透明的方式保护和共享整个系统的资源。因此，虚拟机监控程序(hypervisor)技术在未来车辆 E/E 架构中的作用将日益增大。

虽然 hypervisor 在近十年才开始普遍应用于嵌入式和汽车行业，但其概念早在操作系统开发时就已确立。虚拟机监控程序这个词语源自操作系统的旧称：监督器。hypervisor 实际上就是监督器的监督器，或者可以叫作操作系统的操作系统。2005 年前后，hypervisor 技术在 IT 服务器领域的应用开始迅速增多。主要原因是台式计算机在硬件技术方面的创新大大改进了客户操作系统执行的特权指令的处理。现在，嵌入式 hypervisor 已经开始应用于车辆系统，但大多数仅限于驾驶舱域。

图 5

6. EB corbos Hypervisor 带来独特的功能安全和信息安全性能

EB corbos Hypervisor 是一种为汽车E/E系统开发的裸机虚拟机监控程序。

它可以为典型的基于微内核的嵌入式操作系统提供本机执行环境，也可以为Linux等虚拟化来宾操作系统提供执行环境。

EB corbos Hypervisor 与竞争对手的显著区别在于基于功能的 L4Re 操作系统 [https://www.kernkonzept.com/l4re-operating-system-framework] 及其微内核架构的功能安全和信息安全属性。

Kernkonzept 开发的 L4Re 操作系统已经广泛应用于汽车领域之外的行业。L4Re 支持安全网络、高可信云计算、工业物联网和智能家电等领域的工业应用。L4Re 已帮助各领域的客户构建注重功能安全、信息安全和实时性的灵活系统。

图 6
L4Re 微内核架构的强大之处在于能够最大限度地减少可在特权模式下运行的代码量。对于 EB corbos Hypervisor，同大多数辅助操作系统功能一样，用户进程和来宾操作系统在非特权模式下运行。因此，系统故障或对设备驱动程序等组件的攻击将包含在设备驱动程序运行的上下文中的用户空间进程中。微内核、用户级进程以及虚拟机的内存空间相互隔离，以防各元素之间发生干扰。这提高了整个软件栈的稳健性、功能安全和信息安全。如果设备驱动程序等组件发生故障，微内核可以像任何用户应用程序一样停止整个服务，然后重启。

下表概述了 EB corbos Hypervisor 的功能、它对虚拟化操作系统的支持以及它对功能安全的支持方式。

图 7
总体而言，EB corbos Hypervisor 提供的框架可用于将具有混合关键性的来宾操作系统和本机进程无缝集成到同一硬件平台上。接下来，我们将讨论因将 ECU 整合到同一平台而产生的七项新需求，并解释 EB corbos Hypervisor 为何以及如何满足这些新需求。

需求 1：硬件抽象透明化

操作系统假设它对其运行的硬件平台享有专有控制权。在操作系统之间透明共享硬件的传统技术被称为虚拟化，期间虚拟机用于封装（来宾）操作系统、其用户空间和应用程序。

通过虚拟化，可减少整合车辆 E/E 架构的变体数量，从而限制对 hypervisor 中新硬件平台的支持。最后，这有助于降低整合车辆 E/E 架构的持续开发和维护成本。

为支持整合车辆 E/E 系统的可移植性和可扩展性，操作系统层应提供平台硬件的普通视图。

在 EB corbos Hypervisor 内部运行时，硬件平台会被虚拟化；从操作系统只能看到平台硬件的普通视图。EB corbos Hypervisor 还支持将硬件设备分配给特定的虚拟机。由于裸机监控程序负责将硬件设备暴露给托管操作系统，所以它可以控制哪些硬件设备可以访问。因此，系统设计者可以对哪些硬件设备由虚拟机专用、哪些硬件设备可以共享进行细粒度控制。这种模块性可用于构建高度可扩展的系统，避免单独开发的系统功能之间出现干扰。

需求 2：预配置环境

在分布式开发设置中，每个合作伙伴都需要在定义明确的开发环境中开发他们自己的软件。否则，在后续软件集成过程中，软件的运行时行为可能会不一致。例如，由于目标开发环境中缺少库或库的版本不同，可能发生集成冲突。

为确保单独开发的系统功能够无缝集成，操作系统层应该为每个开发合作伙伴提供一个定义明确的开发环境。

EB corbos Hypervisor 支持预配置执行环境的使用。这些执行环境其实就是已配置操作系统的映像，其提供了一种快速可靠的分布式开发过程加速方式。同时，预配置的执行环境可确保开发合作伙伴使用的执行环境能够满足整合车辆 E/E 架构的整体质量、功能安全和信息安全需求。

需求3：优先启动

由于会分配给整合车辆 E/E 架构多种功能，所以使用确保关键系统功能快速启动的机制至关重要。必须确保非关键系统功能不会干扰关键功能的启动时限。

当然，可以在应用层面实现优先级排序，例如通过系统功能的协同调度。但是，这种设计策略会因系统功能之间引入了非重要依赖关系而增加各个系统功能设计的复杂性。

为确保启动时关键功能可以立即生效，操作系统层应使特定任务或操作系统优先启动。

EB corbos Hypervisor 支持虚拟机启动的透明优先级；系统架构师必须关注 hypervisor 启动策略。这样可以确保系统资源优先分配给重要的系统功能，以便尽早完成其初始化。这还可以确保在hypervisor上运行的系统功能不会感知到系统中不相关元素的启动行为。

需求 4：中间件层分区

操作系统的一个重要功能是与应用软件共享全局软件资源。例如，可在启动时加载共享库，而非直接将库构建到应用程序中。这可以降低软件的整体 ROM 需求。此外，共享库还能在不更新使用库的各个程序时单独更新库。

有时，在操作系统生命周期内频繁出现的问题被称为“依赖地狱”。这个问题通常在中间件层支持的框架数量增加时出现，而每个框架所需的库和操作系统接口版本最终将会有所不同。因此，框架必须定期更新，集成到新版库中，即使框架本身无需更改也应如此。或者，可能需要通过降级库的版本来适应同一操作系统上运行的遗留框架。

为支持多种中间件框架，操作系统层应提供用户空间软件资源分区。

EB corbos Hypervisor 在操作系统层对系统进行分区。这可以减少应用软件使用的必要共享库和服务发生冲突。实际上，每个操作系统实例都提供了可以独立控制的配置，可减少维护不同系统功能所需的各操作系统配置的总体工作量。

需求 5：功能安全的执行环境

为功能安全相关应用程序提供功能安全的执行环境，帮助它们实现功能，同时不会因整合车辆 E/E 系统故障而对人员造成伤害。为确保执行环境安全，须满足以下三个要求。首先，底层硬件-软件接口必须按照预期发挥功能。第二，应用软件运行的操作系统必须按照预期运行。第三，不得干扰系统的所有功能安全相关元素。

为支持混合关键应用程序的执行，操作系统层应该为功能安全相关的应用程序提供安全的执行环境。

EB corbos Hypervisor 满足 ISO 26262 要求的功能安全相关开发和验证流程，为功能安全相关应用程序的安全执行环境提供支持。这可以降低hypervsior代码中出现运行时错误的可能性，并确保以安全的方式使用硬件接口。此外，EB corbos Hypervisor 通过系统硬件和软件元素分区，实现系统层在空间和时间上互不干扰。

分区可提供简单而有力的论据，即在以不同信任级别开发的组件之间不可能存在潜在干扰。虽然分区可以在整合车辆 E/E 架构的软件架构中的不同层级实施，但在裸机上运行的微内核 hypervisor 是分区完成的最有效论据。这是因为在软件架构的更高层级，潜在干扰的接口数量更大。在单个操作系统中进行分区时，需采取更多措施来确保识别并缓解系统库和操作系统内核本身可能出现的所有干扰问题。

需求 6：信息安全的执行环境

由于对连接系统功能的支持不断增加，信息安全将在整合车辆 E/E 架构中发挥更重要的作用。操作系统和中间件框架中的漏洞可能导致漏洞利用，导致分配给整合车辆 E/E 架构平台的系统功能被滥用。

为避免或减轻整合 E/E 系统对关键资源的威胁，操作系统层应提供可靠的执行环境。

EB corbos Hypervisor 通过将所有 hypervisor 资源封装为只能由微内核修改的功能，来降低加密服务、用户数据访问、网络信息流和身份访问控制等资产受威胁的风险。访问系统架构师未配置功能的尝试可被立即检测到。实际上，这些功能可在整合车辆 E/E 架构的进程和操作系统实例之间建立安全边界。此外，它们可以用于在彼此之间建立可信通信通道。

需求 7：支持独立系统开发生命周期

车辆系统功能的开发和集成通常在几个车辆抽象层迭代进行。系统工程进程用于确保集成系统功能在集成到更高车辆抽象层时按设计方式运行。系统功能之间不必要的依赖会导致开发成本增加，开发周期延长。

为支持高效的系统工程进程，操作系统层应支持车辆单个功能开发之间的松散连接。

EB corbos Hypervisor 在进程或虚拟机层提供隔离的执行环境，专门分配给单个组织单元。由于一个系统功能的执行环境对驻留在其他分区的其他不相关系统功能的影响降低，整个系统集成过程将会得到简化。

7. 结论

如上述需求所述，OEM 厂商可利用 EB corbos Hypervisor 实现未来的整合车辆 E/E 架构。根本原因在于 EB corbos Hypervisor 启动系统的组合性。随着整合车辆 E/E 架构的需求不断多样化，依赖高度集成的中间件层和操作系统层的一体化软件架构开始失效。虽然一体化软件架构曾经可能适用于车辆内隔离的遗留 ECU，但为进行扩展，整合车辆 E/E 架构的软件架构需要过渡到组件之间依赖性较低的组合平台。

持续使用一体化软件架构会在系统层和组织层引发诸多问题。首先，组织内的业务部门必须掌握矩阵组织结构，对同一平台上运行的其他业务部门开发的系统功能进行补充。因此，需要加强同步业务部门之间的开发和维护活动。

其次，OEM 厂商和一级供应商需对操作系统层的竞争需求进行管理。在很多情况下，单个平台无法满足这些需求。所以，某些系统功能可能无法如期执行，或者在某些情况下可能无法实现。

功能安全和信息安全也是混合关键软件架构面临的主要问题。必须为系统的所有元素，包括其中运行的开源软件，提供共存标准。在系统复杂性达到某种程度时，如果开始时未考虑，就不可能真正实现功能安全和信息安全。

有些矛盾的是，整合车辆 E/E 架构一体化系统的维护工作量可能会急剧增加。这是因为平台软件元素之间的依赖性增加。软件元素的任何小变更都可能需要在许多系统元素之间同步。但是，在组合系统中，变更仅影响单个子系统，减少了按要求实现、验证和部署变更的工作量。

现在应该清楚的是，将 ECU 整合到单个高性能平台上的未来车辆 E/E 架构需要采用一种新方法来设计, EB corbos Hypervisor 恰恰可以很好地支持这种方式。EB corbos Hypervisor 为信任级别不同的系统元素提供了功能和信息均安全的执行环境。此外，它支持系统资源的透明共享，能够创建可最大限度降低系统元素间依赖性的可扩展平台。最后，EB corbos Hypervisor 为分布式开发环境中的开发活动奠定了基础。

EB corbos Hypervisor 是实现未来车辆 E/E 架构的重要组件。EB corbos Hypervisor 是一种为汽车E/E系统开发的裸机虚拟机监控程序。

它可以为典型的嵌入式操作系统提供本机执行环境，也可以为 Linux 等虚拟化操作系统提供执行环境。

EB corbos Hypervisor 与竞争对手的显著区别在于基于功能的 L4Re 操作系统 [https://www.kernkonzept.com/l4re-operating- system-framework] 及其微内核架构的功能安全和信息安全属性。

Kernkonzept 开发的 L4Re 操作系统框架已经广泛应用于汽车领域之外的行业。L4Re 操作系统框架支持安全网络、高可信云计算、工业物联网和智能家电等领域的工业应用。各领域客户已开始构建注重功能安全、信息安全和实时性的灵活系统。