车辆架构的演进，云原生就绪的ECU如何成为关键？

概要

根据麦肯锡公司的报告，汽车行业的软件和电子技术已经取得了重大突破。随着自动驾驶、互联汽车、动力系统的电气化以及共享出行（ACES）的破坏性力量的推动，软件定义的车辆架构正迅速成为现实。该公司预测，到2030年——在三到四代车辆中，70%的车辆将拥有软件定义的架构。因此，整个汽车产业链上的企业现在必须开始充分利用这一潜力。

电子电气架构演进

在2017年之前，传统驱动的车辆以离散的电子控制单元（ECUs）及其分布在整个汽车中的嵌入式软件为特征。这些来自各个供应商的部分基本上由OEM组装，从软件的角度来看几乎没有增值。如果ECU出现故障或需要更新，就需要经销商的合格工程师进行手动更换。

从2017年开始，OEM们已经开始考虑诸如车身控制、动力系统和信息娱乐等领域，并采用了一定程度的计算集中化。这种领域概念现在已经发展成为一种跨领域的物理区域基础的电子/电气（E/E）架构，该架构将大量离散的ECUs高度集成，以利用更少的、本地化的、性能更高的计算机系统。

这种转变背后的原因是为了降低布线、重量和复杂性，同时提高效率。但是，通过在软件中定义更多元素来完成更多工作的能力为日益增加的复杂性敞开了大门。OEM继续将其分区架构延伸至服务器化，进一步通过在更大的高性能计算(HPC)单元上集成更多软件来减少计算单元的数量。

到2030年的云原生就绪的汽车将继续在车上执行许多关键的实时功能，如防抱死制动系统代码。云端可以通过公有云或私有云设置来提供额外服务，如根据当前位置或目的地为可用停车位提供路线指导。

电子/电气架构已经取得了长足的进步，开始使用敏捷开发模型。在未来几年内，OEM将采用一种软件开发和IT运维(DevOps)类型的环境，实现持续集成、持续测试和持续交付。这个能力的重任将由容器承担。

什么是容器化？

容器化是模块化的进阶，其核心思想是通过检查多个软件系统来识别可复用的区域。这些区域随后被隔离成不同的模块，以实现清晰的功能划分和问题定位。容器化将包含操作系统（OS）库和依赖项的模块打包，使得在任何硬件计算环境中都能够一致地运行轻量级可执行文件。

云计算技术的集成到车辆中，旨在提供全新的功能、服务和体验。为了实现这一目标，首先需要通过抽象、模块化和容器化等手段来消除现有的电子控制单元（ECUs）。这种集成方式能够有效地提高系统的灵活性和可扩展性，为车辆的功能升级和创新提供了坚实的基础。

容器简化管理

传统的嵌入式系统中的软件管理是一项代价高昂的任务，可能需要更新几十个软件解决方案。这些解决方案通常是单体的，具有专有性质，因此确保它们在车辆中可靠工作是一个巨大挑战。

相比之下，由Open Container Initiative (OCI)支持的自包含包是一个容器，它使部署运行时与平台无关。OCI指定了容器如何从实验室移动到公共或私有容器注册表，并在安全框架内为云就绪车辆提供访问。最后，需要一个工具来管理从云到车辆边缘的容器交付。广泛用于云软件开发的Kubernetes开源容器编排系统是此步骤的明确选择。因此，容器化是一种允许轻松管理各个面向服务的代码块的模型。由于超过60%的后端开发人员已经使用容器来构建和部署软件，它是软件架构的首要逻辑和必要元素。

可直接迁移的设计

传统ECU设计方法正面临日益严峻的挑战，难以为继。以现有的自动列车开放式系统架构（AUTOSAR）环境为例，实时环境（RTE）、基本软件（BSW）和操作系统层都位于ECU硬件之上。每个功能特性，如驾驶员疲劳识别、车道偏离警告或速度表，都是独立于ECU实现的单一模块。这种架构由于其僵化的方法使系统难以维护和升级，与朝着云原生就绪车辆发展的进步格格不入。

在云原生就绪环境中，采用“直接迁移”或重新托管的方法可以降低迁移过程所固有的工作量和成本。这种方法只需将一个完整容器中的精确应用程序副本从其传统环境或云端迁移到基于多核SoC的高性能计算（HPC）的全新集成环境中即可。

工程师可以通过两种方式之一来实现“直接迁移”。他们可以提升打包在容器中的AUTOSAR堆栈，并使用运行在操作系统上的容器引擎进行部署，该容器引擎位于托管型Type 1虚拟机监视器上。或者，可以将应用程序、操作系统和虚拟机监视器容器化，以使运行环境更加可预测。

下图展示了直接迁移设计的第一个优势，即软件的可重用性。在旧的单体式软件架构中，存在显著的软件组件之间的依赖关系。这意味着当一个组件中的代码发生更改时，可能需要在整个代码库中进行级联更新。然而，面向服务的架构的容器化方法减少了这种依赖关系，并将代码更改限制在相关组件中。这种方法使得软件更加灵活和可扩展，从而提高了开发效率和软件质量。

架构演进的考虑因素

硬件和软件方面的考虑因素会影响落地的类型和变更的速度。

硬件注意事项包括：

成本：现有ECU中的微控制器相对SoC来说很便宜。尽管所需的HPC单元更少，但仍需仔细评估所需的竞争力与可能造成的成本之间的权衡。

功耗：考虑到动力总成的电气化，比较大量微控制器（功率较低，效率较低）与较少SoC（功率较高，效率较高）的总功耗很重要。

I/O可用性：较少的HPC单元可能意味着比所需的I/O更少。尽管硬件供应商正在解决这个问题，但在选择SoC时仍需考虑此问题。

供应链：随着芯片供应现在成为一个挑战，理解维持现有供应商关系而不是寻找承诺新功能的新的HPC供应商的影响是至关重要的。

布线：这是汽车行业在设计变更时必须考虑的一个关键因素。例如，将车门作为一个独立的区域并为其配备HPC（高性能计算机）系统可能会带来诸多益处。这样一来，不仅可以避免为电动车窗、车门锁以及扬声器和灯光分别布设额外的线缆，还能实现更加简洁、高效的整车设计。

向云就绪转型的软件注意事项包括：

模块化：在考虑向云就绪转型时，必须仔细评估遗留软件是否具备模块化的特性。如果无法实现模块化，可能需要将整个软件整体移入容器中进行部署。

代码可用性：在进行代码迁移时，必须认识到遗留代码的可用性可能存在一定的限制。过时的功能仅存在于二进制文件中，这可能会对未来的灵活性产生一定的影响。因此，在进行这种转换时，需要权衡当前额外付出的努力与未来灵活性的损失。

开销：面向服务的架构（Service-oriented architecture，SOA）在软件层数方面具有更多的层次。管理程序没有额外的开销，但为了满足严格的时序约束，必须考虑实时操作系统（Real-time Operating System，RTOS）所带来的额外开销。

成本：在进行面向服务的架构迁移时，需要充分考虑变革所需的成本。这包括时间和工作的投入，以及可能产生的额外费用。同时，还需要根据紧迫的截止日期和其他限制因素来评估整个变革的成本，并在决策过程中进行权衡和调整。