在亚马逊云科技中模拟汽车 E/E 架构 — 第 1 部分：加速 V 模型

在过去的15年中，汽车电气/电子（E/E）架构的复杂性不断增加，其中包括电子控制单元（ECU）、相关传感器、执行器和车辆内部布线。汽车制造商没有继续向E/E架构添加新的硬件组件，而是转向将较小的固定功能ECU整合到更大的高性能计算机（HPC）中，同时保留较少数量的专用分布式ECU。这为汽车制造商带来了好处，包括但不限于减少车辆的布线和重量。借助这些 HPC 的计算能力，汽车制造商正在创建具有丰富的新用户体验和频繁的软件更新的完整软件平台。由于现代 E/E 架构混合使用 HPC 和固定功能 ECU，因此必须验证它们之间的互操作性，这推动了汽车行业对整个子系统虚拟验证的需求增加。

该博客系列由两部分组成。在第 1 部分中，我们解释了汽车 E/E 架构的趋势，以及汽车制造商在利用云仿真 ECU 软件方面面临的一般概念和挑战。在第 2 部分中，我们将介绍汽车制造商如何利用 dSPAC E VEOS 和利用亚马逊云科技 Graviton 的原生 ARM for HPC 映像，使用亚马逊云科技和 dSPACE 技术来帮助模拟汽车 E/E 架构。

现代汽车 E/E 架构

最近的汽车 E/E 架构通过在域控制器上整合相关功能，解决了管理许多单一功能模块的复杂性。这些 “域集中式架构” 包含每个主要领域的主要计算单元，例如ADAS（高级驾驶辅助系统）和动力系统。域控制器通过网关相互通信，以实现跨域功能，例如在与信息娱乐域相关的屏幕上监控 ADAS 应用程序的状态。传感器和执行器通过 CAN、LIN 或汽车以太网等汽车总线连接到域控制器。

随着汽车制造商考虑进一步减少零部件数量的方法，“车辆集中式架构” 越来越受欢迎。现在，域控制器中提供的功能可以进一步整合，并由个位数 HPC 取代。通过高速以太网连接，HPC 与 Zonal ECU 通信。其中少数几个位于车辆的特定地理位置，并连接到其所在位置的所有传感器和执行器。如图 1 所示，这减少了车辆内部的布线。

Figure 1 Conceptual EE Architecture diagram

图 1：概念性 E/E 架构图

物理 ECU 数量的减少并未减少汽车软件的测试和验证工作。车辆中心化架构使更复杂的汽车软件（例如跨域）成为可能，从而在车辆的生命周期中实现额外的连接（例如V2X）、持续的软件更新和新的软件功能。

汽车软件开发模型

在现代软件开发中，开发人员使用 DevOps ，它结合了文化理念、实践和工具，可提高组织高速交付应用程序和服务的能力。需要持续集成 (CI)，因为开发人员定期将其工作合并到一个可以运行自动构建和测试的中央存储库中。CI 的主要目标是尽早发现并解决错误，以提高软件质量并缩短从功能构思到发布的时间。

但是，在汽车行业中，有一些设计标准，例如用于功能安全的 ISO-26262 和 ASPICE （基于ISO/IEC 15504的汽车软件流程改进和能力确定），这有助于解决汽车软件组件的设计方式。ISO-26262 和 ASPICE 基于 V 模型，这是一个基于传统瀑布模型的开发过程。瀑布模型是一种线性软件开发方法，其中每个阶段都必须先完成，然后才能开始下一个阶段。它被汽车制造商和供应商使用，强调了在整个开发过程中进行测试和验证的必要性。V 模型由两个阶段组成，左侧是 “设计” 阶段，右侧是 “验证阶段”。如图 2 所示。

Figure 2 Automotive V-Model Development Process

图 2：汽车 V 型模型开发流程

在设计阶段，开发人员在测试阶段开始验证之前，预先定义系统设计、规格和要求。此过程可能导致发布周期延迟，并延迟发现错误和错误。显然，汽车制造商需要一种方法来利用现代 DevOps 提供的速度和敏捷性，同时仍支持行业所需的设计标准。

“向左移动”

亚马逊云科技和 dSPACE 正在努力使用云端仿真技术 “向左移动” 对车辆集中式架构系统的验证和验证。这些仿真技术通过并行运行测试用例，帮助汽车行业加速 V 模型中通常定义的验证过程。这包括在开发周期的早期转移测试活动并在云中大规模启用测试活动，而不是等待问题更难解决、成本更高的流程的正确一面。通过使用云原生 DevOps 和仿真尽早发现缺陷，工程师可以降低出现代价高昂的错误的风险，并有助于提高软件的整体质量。左移测试还有助于降低成本和加快上市速度，因为它可以更频繁地进行反馈循环，更早地发现代价高昂的问题。

尽管 Shift-Left 模型增加了完整软件环境中所需的测试数量，但它并未减少使用硬件在环 (HiL) 系统进行系统和集成的需求。取而代之的是，Shift-Left 模型只会增加对开发周期早期测试的关注。汽车软件开发团队可以通过更具成本效益的 SiL 测试来快速迭代 V 模型，从而使用通过云原生 DevOps 提供的更敏捷的开发方法。在他们的开发过程中应用这些方法可以提高质量，并忠实于 V 模型的意图。

仿真模型

在组合完全虚拟的仿真系统、进行实验和自动测试之前，E/E 架构的所有组件都必须适用于虚拟环境。对于车辆集中式架构，这些组件包括边缘、区域ECU和HPC。在无法获得虚拟 ECU 的情况下，可以创建仿真模型来模拟实际传感器和执行器的特性。有几种类型的仿真模型可用，它们可以分为工厂、环境或残余总线模型。为了在所有虚拟组件之间建立通信，还必须在需要时设置虚拟 I/O 连接和总线。图 3 显示了我们的目标仿真系统的代表性方框图。

Figure 3 Simulation System IO and Model Representation

图 3：仿真系统 I/O 和模型表示

虚拟化所有控制单元是创建虚拟仿真系统的关键。为了解释一般方法，我们考虑了以下图 4 中 ECU 和 HPC 四个主要层的概要草图。

Figure 4 ECU layers block diagram

图 4：ECU 层方框图

需要使组件能够在与目标硬件分离的开发环境中运行，而不是依赖具有特定外围设备和连接的目标硬件。

为了进一步说明，区分与区域架构相关的两种类型的操作系统很有帮助： OSEK OS -like 和 POS IX。这些操作系统对于将软件从硬件依赖关系中抽象出来非常重要，因为它们遵守允许跨不同嵌入式平台兼容的标准。

Edge 和 Zonal ECU 通常建立在类似 Osek 的操作系统之上。它们在微控制器上运行，由于占用空间小，并且针对实时应用进行了优化，因此非常适合嵌入式编程。 AUTOSAR 经典平台就是类似 OSEK 的堆栈的一个例子。dSPACE VEOS 的一个关键功能是对此类组件进行仿真。

dSPACE VEOS 基于云的仿真

dSPACE VEOS 是一个用于 ECU 软件验证的仿真平台。它支持各种不同的模型，例如功能模型、功能模拟单元 (FMU)、虚拟 ECU (V-ECU) 和车辆模型，不受任何特定的仿真硬件的影响。

VEOS 还涵盖了与虚拟 ECU 网络相关的总线仿真需求，因为它无需额外的硬件即可模拟汽车以太网、CAN 和 LIN 总线通信，包括所有总线特定的效果。

凭借其连接和使用现有工具的开放接口，VEOS 还支持协同仿真设置，可以在其中以分布式方式对不同的子系统进行建模和仿真。协同仿真允许在不同工具之间进行时间同步和交互。

VEOS 在标准 PC（Windows 和 Linux）上运行，易于集成到基于云的解决方案中，这为功能开发人员、软件架构师和 ECU 测试人员提供了各种有价值的 SiL 测试选项。

为了模拟 Edge 和 Zonal ECU，VEOS 提供了经过调整的操作系统，使我们能够在 VEOS 和 x86 环境中执行应用层和基础软件的更多部分。

VEOS 提供了多个模块来抽象 I/O 和总线驱动程序。因此，我们可以运行基于 OSEK 的组件，并在 I/O 和总线级别上连接它们。

Figure 5 Edge Zonal ECU simulation on AWS 图 5：亚马逊云科技上的边缘/区域 ECU 模拟

通过调整 “操作系统/内核/驱动程序” 层，还可以避免芯片仿真并实现合理的仿真性能。当然，调整不得对行为产生重大影响，以产生有意义的仿真结果。

另一个类别是 POSIX，通常与区域架构中的高性能计算机 (HPC) 有关。HPC 在性能、架构方面更接近 IT 服务器，并提供在需要保持高度可靠性的同时执行要求苛刻的算法的能力。

在保持高性能的同时，它们还需要节能，汽车制造商已采用基于ARM的处理器作为此类HPC的计算核心，并结合硬件加速器。它们已经是车载信息娱乐和ADAS等多个领域的首选，有望成为SDV（软件定义车辆）的计算推动力。

用于 HPC 仿真的亚马逊云科技 Graviton

亚马逊云科技提供名为 AW S Graviton 的基于 64 位 ARM 的定制处理器，旨在为云工作负载提供高达 40% 的最佳性价比提升。通过在越来越多的实例类型（包括硬件加速器）上使用这些处理器选项，汽车开发人员可以使用同样用于嵌入式汽车平台的 Arm 知识产权 (IP) 和工具，开发和运行基于 POSIX 的 HPC 应用程序和工具链。这允许直接执行 Arm 指令集架构，无需交叉编译。

Figure 6 HPC simulation on AWS 图 6：亚马逊云科技上的 HPC 模拟

但是，值得注意的是，基于亚马逊云科技 Graviton 的系统与车辆中使用的 SoC 和 ECU 并不完全相同。例如，这些云系统上没有物理 CAN 总线。亚马逊云科技和 dSPACE 通过在开发周期的早期解锁和增强 SIL 功能来帮助创造价值。因此，也可以看出 HiL 验证仍将是一项要求。可以直接考虑 CPU 奇偶校验等方面，也可以使用重播消息进一步模拟输入和输出的差异。汽车工程师还可以模拟或模拟系统中不存在的硬件外围设备。

为了使这种方法取得成功，我们还必须确保开发虚拟机管理程序的软件供应商以及在汽车领域使用的操作系统也在亚马逊云科技 Graviton 上运行。今天，我们有几个用于汽车行业的亚马逊系统映像 (AMI) 已经移植到原生的亚马逊云科技 Graviton 上，例如黑莓 QNX 和嵌入式 Linux 。