混合关键性处理的下一步发展

随着消费者越来越期望车辆具有先进的功能，OEM 正在寻找新的方法在优化计算资源和成本的同时来满足这一需求。通过混合关键性处理将 ADAS 和座舱域融合在单个高性能计算平台上， 可以帮助 OEM 提高效率和简化车辆架构来实现这一目标，从而使 OEM 能够在优化成本的同时实现功能丰富的系统。

不过，这种融合也带来了特有挑战，超出了当前混合关键性处理的应对能力。

混合关键性处理的现状

要了解混合关键性处理，首先必须了解汽车安全分类系统。ISO 26262汽车功能安全标准概述了汽车安全完整性等级 (ASIL) 的分类系统，该系统包括四个风险级别：ASIL-A（最低级别）至ASIL-D（最高级别），这是对高级安全应用的评级。第五级，即质量管理 (QM)，分配给不需要降低风险的功能，因为标准质量管理实践已经足够了。在混合关键性处理中，单个计算平台用于支持具有不同安全级别的应用。 

汽车 OEM 目前在功能的底层硬件要求相同的情况下采用的混合关键性系统方案是使用虚拟机来提供专用资源。以集成座舱控制器（其多个型号自 2018 年以来已陆续上市）为例：仪表盘应用归类为 ASIL-B，而 Android 信息娱乐系统则被归类为 QM。两者均需要图形处理单元 (GPU) 来显示信息，因此可在单个芯片上运行并共享资源，这样可将系统成本降低 20%。

不过，在基本硬件和软件需求方面，ADAS 与座舱域截然不同 — ADAS 功能集需要失效安全设计和访问更多加速器，例如神经网络处理单元。这些差异会使得在混合关键性场景中融合这些功能区域变得更加复杂。

融合 ADAS 和驾驶舱域的构建模块

要在单个高性能计算平台上成功融合 ADAS 和座舱域，以下构建模块至关重要：虚拟机管理程序、 实时操作系统 (RTOS)、容器和中间件。

虚拟机管理程序

虚拟机管理程序是使用虚拟化技术来创建、运行和管理虚拟机的软件。虚拟机管理程序的一个关键优势是，支持特征迥异的多个操作系统同时运行，共享相同的虚拟化硬件资源，而不会相互干扰。否则，一个硬件系统上只能运行一个操作系统。

嵌入式系统（例如汽车应用中的系统）具有严格的资源使用限制 — 虚拟机管理程序必须要遵循这些限制，同时实现具有低延迟的快速通信。RTOS 对于实现这种快速通信至关重要。

RTOS

RTOS 是一种专用操作系统，可在明确定义的时间限制内处理数据并执行操作。RTOS 有两个主要特性：可预测性和确定性。在 RTOS 中，重复性的任务会在严格的时间范围内执行，这意味着每次执行每项任务的时长必须完全一样，并且必须能够始终产生相同的结果。

容器

软件容器 对于 RTOS 执行目标更新是不可或缺的。如果考虑到 ASIL-D 级系统在每次部署更新时都需要重新测试，软件容器更是尤为关键。如果没有软件容器，对座舱域的任何更新都需要重新测试整个系统。容器化微服务还有助于将复杂的软件系统分解为小型独立服务，从而减少更新的规模。

中间件

在真正的软件定义汽车架构中，中间件是 硬件、操作系统和应用软件之间的粘合剂，为各个车辆域提供通用服务并允许特定域开发人员构建这些功能。此外，中间件还支持通过面向服务的模块化方法使应用程序不依赖于硬件。

采用系统级方法实现利益最大化

融合实现了在成本和性能之间的理想平衡，同时有助于实现 ADAS 和座舱域的可扩展性和模块化。不过，融合的许多优势（例如降低成本和缩短开发时间）只有通过采购一体化解决方案才能实现。如果 OEM 分开采购硬件和软件，那么开发团队集成解决方案的负担会变大。通过将 RTOS、中间件和虚拟机管理程序整合到单个可扩展的集成解决方案中，OEM 可以更加专注于开发品牌差异化功能。

作为系统集成商，安波福是帮助 OEM 更大程度地从 ADAS 和座舱域融合中受益的不二之选。2022 年，我们收购了风河，该公司是为任务关键性智能系统提供软件的全球领导者。风河的 Helix 虚拟机管理程序平台通过将多个操作系统和混合关键性应用程序整合到共享系统上，可简化设计、提供保护并满足未来需求。风河的 VxWorks® 是业内唯一支持Open Container Initiative (OCI) 合规容器的 RTOS，可确保在不同步平台和环境中的兼容性和易用性。安波福和风河携手，可帮助 OEM 开发一体化解决方案，以降低成本、缩短开发时间并满足其独特要求。