软件定义的工具将看到系统架构借鉴通常与云计算相关的方法，例如虚拟化；因此，支持细粒度硬件分配以支持虚拟化ECU的设备将成为汽车系统开发的主要内容。

对于普通车主来说，汽车市场正在发生变化。除了汽油和柴油，还有电动化的选择。其中包括混合动力、全电池供电和氢气。但这些并不是正在发生的唯一变化，汽车的基础电气和电子架构（E/E）也在发生变化。随之而来的是，车内电子设备的设计方式以及驾驶员和乘客进入车内后的体验发生了重大变化。

自20世纪70年代以来，随着原始设备制造商（OEM）开始集成电子燃油喷射（EFI）系统和车内诊断，微处理器逐渐渗透到汽车中。随着越来越多的电子控制单元（ECU）中的每一个都内置了一个或多个，它们对汽车的安全、效率和舒适性做出了逐年的贡献。从网络角度来看，这导致了一个扁平的架构，在车辆建成后，几乎没有空间提供功能升级。

实现一项功能所需的一切，从传感到启动，都连接到一个ECU。通常，ECU通过CAN等总线连接到支持控制、编程和诊断的中央系统。一旦部署，软件只有在确定了问题并且经过大量努力、测试和车辆召回后才能更新。

智能手机对汽车的影响

然而，一代智能手机用户正在影响对产品体验的期望。消费者不再期望购买成品；他们购买的平台可以根据他们的需求、要求和生活方式进行修改和配置。昨天对车辆设计的僵化做法不符合这种模式。这迫使汽车行业重新考虑其车载电子设备和实现其大部分功能的软件的方法。

目前有两种E/E架构流派，这两种流派都减少了ECU的数量，简化了电缆绝缘和网络，并使空中（OTA）更新成为可能。它们还提供了允许功能所需的结构，如座椅加热装置，将在车辆配置完毕并交付给原车主后很久，像智能手机应用程序一样购买。其中一个是领域架构，它遵循当今汽车不同领域的命名惯例，例如动力总成、底盘、制动和车身等（图1）。以前在单个ECU上实现的功能与许多其他领域功能一起部署在具有强大多核处理器的单个ECU上（图2）。

图1：汽车系统的扁平架构正迅速被领域和区域架构所取代。

另一种方法是分区架构。在这里，ECU的位置更为相关，车辆周围有少量的硬件盒，靠近安装的传感器和执行器。同样，ECU包含功能强大的多核处理器和冗余高速网络，适合与其他分区控制器交换数据的实时控制。中心有一台高性能计算机（HPC）和一个提供互联网连接的远程信息处理网关。

虽然领域体系结构提供了可以被认为是向更高集成度的简单移动，但区域体系结构将软件开发方法推向了顶峰。这是因为前照灯和指示灯控制等功能分布在区域ECU中，而不是专用于单个盒子。相反，这些功能被实现为功能强大的多核处理器上的虚拟ECU。

对于域和区域架构，这也意味着满足不同汽车安全完整性级别（ISO 26262 ASIL）的软件必须在同一处理器上彼此并行运行，而在发生故障时不会相互影响。这在汽车行业被称为“不受干扰”因此，无论使用何种架构，很明显，软件是定义车辆功能的核心，而这其中的一个核心方面就是虚拟化。

图2：在域控制器中，每个车辆功能都在虚拟ECU上实现，操作系统在管理程序的监视下共享处理性能。

虚拟化的短暂尝试

虚拟化对于云计算的成功至关重要，它使多个操作系统（OS）安装能够在一台服务器上执行，从而在多个用户之间共享其性能。裸机虚拟化在服务器硬件上以最低级别运行，任何已安装的客户操作系统都不知道它是虚拟化的，共享硬件资源，或者其他操作系统与之并行运行。在最纯粹的形式中，虚拟化平台（称为虚拟机管理程序）基本上捕获操作系统调用，并将其转换为虚拟化系统，例如磁盘和内存访问。这同样适用于硬件接口，例如以太网连接。

正如预期的那样，在处理这些硬件访问时，虚拟化具有不可避免的开销。为了解决这一问题，开发人员可以选择半虚拟化的替代方法。这里，硬件资源访问是在软件中实现的，类似于如果只有一个操作系统存在，它们将如何实现。虽然这提供了比虚拟化更高的性能，但其好处因工作负载而异，需要对操作系统进行适当修改。这种水平的差异对于汽车的实时控制来说是不可接受的。

虚拟化操作系统的实时处理器

专用于汽车应用的处理器必须解决这些挑战，恩智浦新一代实时处理器就是如此。例如，开发工程师通常期望通过一系列宽寄存器来配置和控制通用I/O（GPIO）引脚，每个位专用于设置方向、使用上拉、提供输出控制和传递输入状态。这些寄存器中的每一个都在内存中分配了一个地址。因此，典型的内存保护机制无法将寄存器的单个位分配给特定的OS实例。因此，管理程序有责任在软件中处理此问题。

S32Z和S32E提供了一种替代方案，放弃了这一要求，使每个客户操作系统都能支持GPIO引脚的任意组合。通过额外的硬件提供支持，在启动期间，将所需的GPIO引脚分配给特定的客户端OS或系统分区。当这在硬件中实现时，通常与虚拟化相关的性能损失会消失。由于每个操作系统基本上只能看到自己任意数量的GPIO，因此得益于硬件级分区，几乎不需要半虚拟化。

ASIL认证也通过这种硬件级别的虚拟化支持得以简化。硬件中的任何故障只会影响相关操作系统及其应用程序，单个虚拟机可以选择重置或重新启动自己，而不会影响设备上的其他操作系统或硬件配置。失控过程对系统的其他部分没有影响。另一个好处是由此产生的带宽和性能的服务质量保证。

针对软件定义车辆的需求

对GPIO资源的核心到引脚访问是支持软件定义的车辆需求的S32E和S32Z实时处理器系列的一个方面。24个FlexCAN FD网络接口可以标记一个标识符，以便将其分配给特定的客户操作系统，再次将软件开销降至最低。此外，CAN网络可能特别中断，导致许多上下文切换，这使得在应用程序代码的其余部分中实现实时要求具有挑战性。

为了管理这一点，CAN外设是专用自动通信加速块的一部分，该块具有两个专用Arm Cortex-M33锁步内核和768 KB的SRAM（图3）。连接/接口块也支持新的CAN-XL标准。CAN-XL提供高达20 Mbit/s的数据速率和2048字节的更大数据字段。它仍然可以与CAN-FD网络互操作，但也支持更高层协议（如互联网协议（IP））的隧道传输，随着汽车以太网作为汽车主干网的部署，这一点将得到越来越多的应用。

未来，控制车辆功能的过程将通过以太网向实现控制或传递传感器数据的软件过程发出命令。然而，该功能可能在相同的处理器硬件上执行，但在不同的虚拟ECU上执行。为了支持这一点，以太网交换机还可以在处理器上的虚拟ECU之间传递数据。这意味着可以创建通过以太网通信的软件功能，而不需要知道对方软件是在同一处理器上还是在网络上的其他地方的不同分区控制器上。

图3：NXP S32E和S32Z上提供的可用汽车连接的小样本，有时带有加速支持。

软件定义车辆的软件开发

汽车内部软件的开发方式也必须改变。与传统最重要的突破是在汽车原始设备制造商。这里的概述非常重要，确保所需功能得到良好定义，并且所选处理器硬件的性能能够满足当前的期望以及未来驾驶员在车辆使用寿命内的期望（图4）。

图4：在分区架构中，功能分布到整个车辆的虚拟ECU，例如，在这里，前后制动和制动相关ESC集中部署。

一级供应商也将在这方面发挥重要作用，这要归功于他们对各种车辆领域以及历史上如何实施的深入了解。再往下看，2/3级汽车供应商除了转向为虚拟ECU而非硬件ECU开发软件之外，更可能看到更少的变化。他们将能够访问操作系统和外围设备，而对同一硬件上的其他操作一无所知。事实上，这些决定甚至可能还没有做出。这就是软件定义方法的灵活性。

重要的是，所选的处理器为今天提供了充足的性能，为明天提供了更多的空间，以及支持安全OTA更新的能力。S32E和S32Z提供8个Arm Cortex-R52内核，工作频率高达1 GHz，采用16 nm工艺制造，路线图为5 nm。它们可以灵活地配置为单个或锁步内核，以满足在其上执行的功能的安全需求。为了支持高级驾驶员辅助系统（ADAS）和自动驾驶功能的需求，还有一个25 GFLOPS DSP/机器学习处理器。

通过ISO 21434认证的硬件安全引擎（HSE）为安全通信和使用公钥基础设施（PKI）共享的数字签名软件更新提供了安全的密码加速器。

汽车的未来是软件

从外面看，汽车仍然是机械奇迹，从造型和形状到座椅和机动化。但其他一切，从运动到它们为乘客提供的功能，都将由软件定义，再加上电子设备，隐藏在视线之外。汽车一直是一个独特的市场，不仅需要半导体行业能够提供的最快处理器，还需要满足广泛可靠性和安全性要求的产品。

随着软件定义的工具推动系统体系结构的发展，需要一种新的实时处理器，这种体系结构利用了通常与云计算相关的方法，例如虚拟化。支持从核心到引脚的细粒度硬件分配以支持虚拟化ECU的设备将成为部署的新E/E架构中汽车的主要部件。这将使原始设备制造商能够整合硬件并提供智能手机风格的功能，即服务、应用程序和OTA更新，同时保持其品牌赖以建立的可靠性和安全性。

Steve McAslan是一名技术总监NXP半导体。他拥有30多年的开发、专利和将新微处理器技术引入汽车和其他行业的经验。