软件定义的车辆将看到系统架构利用通常与云计算相关的方法，例如虚拟化；因此，支持细粒度硬件分配以支持虚拟化 ECU 的设备将成为汽车系统开发的主要内容。
即使对于普通车主来说，汽车格局正在发生变化也是显而易见的。除了汽油和柴油，还有电气化选择。其中包括混合动力、全
电池供电和氢动力。但这些并不是的变化。车辆的底层电气和
电子架构 (E/E) 也在发生变化。随之而来的是车载电子设备的设计方式以及驾驶员和乘客在车内的体验发生了重大变化。
自 1970 年代以来，随着 OEM（原始设备制造商）开始集成电子燃油喷射 (EFI) 系统和车载诊断系统，微处理器逐渐渗透到汽车领域。随着越来越多的电子控制单元 (ECU) 中的每一个内置一个或多个，它们年复一年地为汽车的安全性、效率和舒适性做出了贡献。从网络的角度来看，这导致了扁平化架构，并且在车辆制造完成后提供功能升级的空间很小。
实现功能所需的一切，从传感到驱动，都连接到单个 ECU。通常，ECU 通过总线（如 CAN）连接到支持控制、编程和诊断的中央系统。部署后，只有在确定问题并且经过大量工作、测试和车辆召回后，才会更新软件。
智能手机对汽车的影响
然而，一代智能手机用户正在影响对产品体验的期望。消费者不再期望购买成品；他们购买的平台可以根据他们的需要、要求和生活方式进行修改和配置。昨天僵化的车辆设计方法不适合这种模式。这迫使汽车行业重新考虑其车载电子产品方法和实现其大部分功能的软件。
目前有两种 E/E 架构思想流派，它们都减少了 ECU 的数量，简化了
电缆束和网络，并使无线 (OTA) 更新成为可能。它们还提供了所需的结构，允许在车辆配置好并交付给其原始所有者后很长时间内像智能手机应用程序一样购买座椅加热等功能。一种是领域架构，它遵循当今车辆不同领域的命名约定，例如动力总成、底盘、制动和车身，仅举几例（图 1）。以前在单个 ECU 上实现的功能与许多其他域功能一起部署在具有强大多核处理器的单个 ECU 上（图 2）。
图 1 - 平面到域区域架构 - NXP
图 1：汽车系统的平面架构正迅速被领域和区域架构所取代。
另一种方法是区域架构。在这里，ECU 的位置更为相关，车辆周围的少量硬件盒更靠近已安装的
传感器和执行器。同样，ECU 包含强大的多核处理器和冗余高速网络，适用于与其他区域控制器交换数据的实时控制。中心是一台高性能计算机 (HPC) 和一个提供互联网连接的远程信息处理网关。
虽然域架构提供了可以被认为是向更高集成的简单迁移，但区域架构颠覆了软件开发方法。这是因为前照灯和指示灯的控制等功能分散在区域 ECU 中，而不是专用于单个盒子。相反，这些功能在强大的多核处理器上作为虚拟 ECU 实现。
对于域和区域架构，这也意味着满足不同汽车安全完整性级别 (ISO 26262 ASIL) 的软件必须在同一处理器上相互协同运行，而不会在发生故障时相互影响。这在汽车行业被称为“免于干扰”。因此，无论使用何种架构，很明显软件是定义车辆功能的，而其方面是虚拟化。
图 2 - S32E 上的虚拟 ECU
图 2：在域控制器中，每个车辆功能都在虚拟 ECU 上实现，操作系统在管理程序的监视下共享处理性能。
虚拟化的简要尝试
虚拟化对云计算的成功至关重要，它使操作系统 (OS) 的多个安装能够在单个服务器上执行，从而在许多用户之间共享其性能。裸机虚拟化在服务器硬件上运行在级别，任何已安装的客户操作系统都不知道它是虚拟化的，共享硬件资源，或者其他操作系统正在与它一起运行。在其纯粹的形式中，称为管理程序的虚拟化平台本质上是捕获操作系统调用并将它们转换为虚拟化系统，例如磁盘和内存访问。这同样适用于硬件接口，例如以太网连接。
正如预期的那样，在处理这些硬件访问时，虚拟化具有不可避免的开销。为了解决这个问题，开发人员可以选择半虚拟化的替代方法。在这里，硬件资源访问是在软件中实现的，类似于如果只存在一个操作系统，它们将如何实现。虽然这比虚拟化提供了性能提升，但好处因工作负载而异，并且需要适当修改操作系统。这种差异水平对于汽车的实时控制世界是不可接受的。
用于虚拟化操作系统的实时处理器
专用于汽车应用的处理器必须应对此类挑战，恩智浦的新一代实时处理器就是这种情况。例如，开发工程师通常期望通过一系列宽寄存器配置和控制通用 I/O (GPIO) 引脚，每个位专用于设置方向、使用上拉、提供输出控制和提供输入的状态。这些寄存器中的每一个都在内存中分配了一个地址。因此，典型的内存保护机制无法将寄存器的各个位分配给特定的操作系统实例。因此，管理程序有责任在软件中处理此问题。
S32Z 和 S32E 提供了放弃此要求的替代方案，为每个来宾操作系统实现了对 GPIO 引脚的任意组合的内核到引脚虚拟化支持。支持是通过附加硬件提供的，这些硬件在启动期间将所需的 GPIO 引脚分配给特定的客户端操作系统或系统分区。由于这是在硬件中实现的，通常与虚拟化相关的性能损失就会消失。因为每个操作系统基本上只能看到自己任意数量的 GPIO，由于硬件级分区，几乎不需要半虚拟化。
这种硬件级的虚拟化支持也简化了 ASIL 。任何硬件故障只会影响相关的操作系统及其应用程序，并且单个虚拟机可以选择重置或重新启动自身，而不会影响设备上的其他操作系统或硬件配置。失控进程对系统的其他部分没有影响。另一个好处是由此产生的带宽和性能的服务质量保证。
针对软件定义车辆的需求
对 GPIO 资源的到引脚访问是 S32E 和 S32Z 系列实时处理器的一个方面，支持软件定义的车辆需求。24 个 FlexCAN FD 网络接口可以用标识符标记，使它们也可以分配给特定的客户操作系统，再次限度地减少软件开销。此外，CAN 网络可能特别频繁地中断，导致许多上下文切换，这使得在应用程序代码的其余部分中满足实时要求变得具有挑战性。
为管理这一点，CAN 外设是专用自动通信加速块的一部分，该块具有两个专用 Arm Cortex-M33 锁步内核和 768 KB SRAM（图 3）。连接/接口块也支持新的 CAN-XL 标准。CAN-XL 提供高达 20 Mbits/s 的数据速率和 2048 字节的更大数据字段。它保持与 CAN-FD 网络的互操作性，但也支持更高层协议的隧道传输，例如互联网协议 (IP)，随着汽车以太网被部署为汽车骨干网，这种协议将得到越来越多的使用。
未来，控制车辆功能的进程将通过以太网向软件进程发出命令，以实现控制或传送传感器数据。然而，该功能可能在相同的处理器硬件上执行，但在不同的虚拟 ECU 上执行。为了支持这一点，以太网交换机还可以在处理器上的虚拟 ECU 之间传递数据。这意味着可以创建通过以太网通信的软件功能，而无需知道对应软件是在同一处理器上还是在网络上其他地方的不同区域控制器上。
图 3 - 汽车连接 - NXP
图 3：NXP S32E 和 S32Z 上提供的可用汽车连接的一小部分示例，有时带有加速支持。
软件定义车辆的软件开发
汽车软件的开发方式也必须改变。与传统重大的突破发生在汽车原始设备制造商身上。此处的概述至关重要，确保所需功能得到明确定义，并确保所选处理器硬件提供的性能能够满足当今和未来驾驶员在车辆使用寿命期间的期望（图 4）。
图 4 - ZonalArchitecture - NXP
图 4：在区域架构中，功能被分配到整个车辆的虚拟 ECU，例如这里集中部署了前后制动和与制动相关的 ESC。
供应商也将在这里发挥重要作用，这要归功于他们对各种车辆领域及其历史实施方式的深入了解。在供应链的更下游，2/3 级汽车供应商除了转向为虚拟 ECU 而非硬件 ECU 开发软件外，变化不大。他们将获得对操作系统和外围设备的访问权限，但对同一硬件上运行的其他内容知之甚少。事实上，这样的决定甚至可能还没有做出。这就是软件定义方法的灵活性。
重要的是，所选处理器要为今天提供充足的性能，为明天提供充足的空间，并能够支持安全的 OTA 更新。S32E 和 S32Z 提供八个运行频率高达 1 GHz 的 Arm Cortex-R52 内核，采用 16 nm 工艺制造，并具有 5 nm 的路线图。这些可以灵活地配置为独立或锁步内核，以匹配在其上执行的功能的安全需求。为了支持驾驶辅助系统 (ADAS) 和自动驾驶功能的需求，还有一个 25 GFLOPS DSP/机器学习处理器。
经 ISO 21434 的硬件安全引擎 (HSE) 为安全通信和使用公钥基础设施 (PKI) 共享的数字签名软件更新提供安全的加密加速器。
汽车的未来是软件
从外观上看，汽车仍然是机械的奇迹，从它们的样式和形状到它们的座椅和机动化。但其他一切，从运动到它们为乘员提供的功能，都将由软件定义，再加上电子设备，隐藏在视线之外。汽车一直是一个独特的市场，不仅需要半导体行业可以提供的快的处理器，还需要同时满足广泛的可靠性和安全性要求的产品。
随着软件定义的车辆推动采用通常与云计算相关的方法（例如虚拟化）的系统架构，需要一类新的实时处理器。支持从内核到引脚的精细硬件分配以支持虚拟化 ECU 的设备将成为部署的新 E/E 架构中汽车的主要部分。这将使原始设备制造商能够整合硬件并提供智能手机式的功能即服务、应用程序和 OTA 更新，同时保持其品牌赖以建立的可靠性和安全性。
