Arm：让软件定义车辆（SDV）成为现实

概述

桑杰：我们又带来了一期《Driving Innovation 》播客的特别节目，本次节目来自拉斯维加斯2024年国际消费电子展（CES 2024）的展场。在本期节目中，我们邀请到了Arm公司汽车业务市场拓展总监罗伯特·戴。罗伯特将详细介绍Arm在汽车领域的布局，以及该公司通过SOAFEE计划推动云原生软件开发的相关举措。希望您喜欢本期节目。

议程

罗伯特：谢谢。首先，我要感谢Sonatus 邀请我们来到他们在2024年国际消费电子展（CES 2024）上的精彩展位，并在此简要谈谈我们Arm如何推动“软件定义汽车”的落地。关于“软件定义汽车”的讨论已有很多，许多人在探索各种不同的途径，力求真正将其变为现实。而这也正是我们今天要探讨的话题。 那么，根据议程，我们将先简要介绍一下Arm是谁，以及Arm在汽车领域的定位。随后，我们将深入探讨什么是软件定义汽车，以及为何要实现软件定义汽车。最后，我们将介绍我们正在推进的若干举措——我们相信，这些举措将推动软件定义汽车成为现实。 首先简要介绍一下Arm。我们是一家技术公司，主要开发用于集成到半导体产品中的知识产权（IP）。在过去30年的发展历程中，我们取得了相当大的成功。正如各位所见，目前已有大量基于Arm的芯片投入市场。据我们估算，全球70%的人口都在使用含有Arm技术的产品。 有趣的是，我曾试着数一数家里有多少款Arm产品，但后来就停了下来，因为实在数得有点难。我们看到，随着Arm从消费电子展上的消费类设备领域，逐步向汽车领域拓展，这一趋势正在加速。而这正是我们今天要重点讨论的内容。

Arm在汽车领域的应用

罗伯特：所以Arm其实在汽车领域已经深耕25年了。好的。 我们几乎一直都在从事车载系统领域。但通常来说，我们更多是“藏在引擎盖下”，如果这样说能让人明白的话。所以，你看，如果参考这里的一些数据，超过85%的车载信息娱乐（IVI）系统都基于Arm运行，这其实很自然，因为IVI系统就像消费类电子设备一样，只不过它们恰好安装在你的车里。 此外，随着新的ADAS功能和自动驾驶技术的引入，许多应用流程也基于Arm技术构建。我们在Arm所做的是开发了针对汽车领域的专用产品。因此，我们拥有CPU、GPU和ISP（图像信号处理器）——稍后我会向大家展示——这些产品的关键特性之一就是功能安全。我们还拥有一个非常出色的汽车生态系统，Sonatus 就是我们的生态系统合作伙伴之一。

为何要采用软件定义汽车

罗伯特：那么，为什么软件定义汽车如此重要呢？首先，从整车制造商（OEM）的角度来看，它使他们能够探索新的商业模式、新的收入模式，以及与客户之间的新型关系。关于软件定义汽车，顾名思义，早期软件开发至关重要。汽车中将搭载大量软件，这绝非一蹴而就之事。明白吗？ 但我们看到，软件定义汽车已成为汽车行业的生存之道。有趣的是，这一进程已经展开。这是去年Gartner的一段引述，大意是：到2023年，排名前十的汽车制造商中，将有50%通过软件更新提供新功能。 这正是“软件定义汽车”的核心所在：你可以将这些功能以软件形式引入，并能对其进行更新、升级，还能添加新功能。这正是其中的关键所在。

我们准备好迎接SDV了吗？

罗伯特：接下来的问题是，作为消费者，我们是否已经做好了迎接软件定义汽车的准备？我们是否愿意为此买单？Aurora Labs 和 Strategy Analytics 曾在 2022 年（我记得是那一年）进行过一项研究，他们询问消费者是否愿意为软件定义的功能和服务付费。如你所见，近 50% 的受访者表示，他们愿意每月支付 20 美元来获取车内额外服务。 这算下来一年可是一笔不小的数目。而且是车辆整个使用寿命期间都要支付。有些人甚至愿意支付高达50美元，这真的相当令人难以置信。我甚至都不想算算这换算下来一年要花多少钱。

针对SDV的新要求

罗伯特：关于软件定义汽车，关键在于它对传统汽车产业提出了新的要求。因此，我们需要能够将软件定义的功能作为先进特性来提供。我们需要推动创新，同时也要具备敏捷性。所以，这更接近于传统的软件领域，而非单纯的汽车领域。这些功能必须可更新、可升级，必须安全可靠。 最后，它们还必须具备可扩展性。构建软件定义汽车的关键之一，就是能够将这些功能和特性扩展到不同车型的车辆上。因此，随着我们步入软件定义时代，观察这种动态将如何发展，将会非常有趣。

Arm的汽车产品

罗伯特：在Arm，我提到过我们有这些汽车类产品，因此我们拥有一系列被称为AE（即汽车增强型）的产品。其中有一款名为Cortex-A78AE的高性能CPU产品。它具备一项名为“分区锁定”（split-lock）的独特功能，实际上可以将成对的核心锁定在一起，以实现更高的安全级别。但如果你需要高性能，也可以解锁它们。 这样一来，基本上就形成了双核架构。这一特性主要体现在我们的AE系列CPU中。此外，我们还拥有一款功能安全型GPU——Mali-G78AE，它具备一种用于实现安全渲染的独特分区机制。 此外，我们还拥有一款名为Mali-C78AE的图像信号处理器（ISP）。所有这些产品对于运行软件定义功能、在车内运行图形应用程序都至关重要，而这些应用程序将成为软件定义功能的一部分。借助ISP，车辆能够获取高保真的摄像头图像，以支持所有ADAS功能及其他相关应用。接下来，让我们转向SDV（软件定义车辆）。

SDV的四大支柱

罗伯特：在与业界交流的过程中，我们逐渐认识到，实现软件定义汽车（SDV）及其落地大致有四大支柱。其中，最关键的两点显然是安全与保障，同时还需要具备实时性。这些本就是汽车行业所必需的，而软件定义汽车同样需要这些要素。 我们需要一些超越传统汽车标准的规范。对于软件定义功能，必须有相应的API和标准，以便我们在此基础上构建这些功能。我们还需要一些新的软件开发方法论。 今天我将就此展开更多讨论，因为这是一种将其他行业的软件方法论引入汽车行业的有趣途径。关键在于——稍后我将详细说明——必须具备在车辆及车载计算系统尚未就绪时运行软件的能力。 必须尽早着手，并开展仿真等工作。而最重要的，我将在最后提到，是行业内的协作。我们不能再存在这种“信息孤岛”了。各方需要通力合作。这个问题过于庞大，单凭一家公司无法独立解决。那么，让我们来简要看看其中的一些方面。刚才我们提到的关键点之一就是新的软件方法论。

现代开发流程

罗伯特：因此，汽车行业当前需要做的是引入现代开发流程，从而有效缩短软件的开发周期和部署时间。此外，我们还需要实现所谓的“环境一致性”——即无论是在云端开发还是部署到边缘设备，如果这两个环境采用相同的指令集，就能让软件既能在云端运行，也能在车载系统中运行，这将非常理想。 关于这一点，我们稍后会再详细讨论。在不同芯片供应商之间实现便捷的部署能力同样至关重要。这能确保软件在不同代车或不同车型之间迁移时的可移植性。此外，这实际上也推动了“左移”策略的实施。我将在下一张幻灯片中对此进行说明。

汽车行业的“左移”策略

罗伯特：因此，这里传统的汽车开发流程相当具有序列化特征。基本上，你先设计软件和SoC，接着开发ECU，最后才进行应用程序开发。这是一种序列化的流程。 如果这些环节尚未就绪，你就很难开展太多的应用程序开发工作。而在我们推行云原生开发时，会引入云端。如果你能尽早在这个云端（即上层）开始应用程序开发，那么在其他环节进行的同时，你就可以在这里同步开展开发工作。这样，我们就能实现并行开发。 待系统集成完成后，方可将系统部署到车辆中进行测试。实际上，我们首先是在这里进行测试和开发。当车辆或车载计算系统准备就绪时，再将其部署下去。这还带来了另一个好处——也就是时间层面的“左移”。它还支持持续的更新和升级，这是软件定义汽车的一个重要因素。 因此，你可以持续地向车辆用户提供新服务或更新后的服务。这在汽车制造商（OEM）与驾驶者之间可能产生一种非常有趣的关系动态变化，因为目前，如果你买了一辆车，基本上就是开着它离开展厅。你与制造这辆车的公司其实并没有太多联系。而现在，如果他们提供更新和服务，情况就不同了。 因此，驾驶者与制造商之间的关系开始发生变化。那么，我们该如何实现这一点呢？

SOAFEE 倡议

罗伯特：所以，几年前，我们发起了一项名为SOAFEE的计划。这是一项行业倡议，旨在为汽车领域的软件定义车辆带来云原生的软件开发体验。明白吗？为此，我们成立了SOAFEE特别兴趣小组。我们首先想做的是尝试定义一种能够实现这一目标的软件架构。 因此，SOAFEE的首要任务是定义架构，而非编写任何代码。不过，为了让大家真正开始应用SOAFEE，我们知道需要有一个参考软件实现，这样人们才能开始开发并尝试这些针对汽车工作负载的新方法。你可以看到，SOAFEE的创始成员和管理成员确实来自整个汽车生态系统。 其中包括整车制造商（OEM）、一级供应商（Tier 1）、云服务提供商、我们自己，以及一些软件企业。例如红帽（Red Hat）和SUSE，它们在软件开发及其整体整合方面拥有深厚造诣。因此，我们相信仅凭这些管理机构，我们就对目标方向有了清晰的认识。稍后我会向大家进一步介绍SOAFEE的成员构成。

云原生架构

罗伯特：但我跟你们说过，我们真正试图定义的是一个架构。正如你们在这里看到的，我们有一个包含云端组件和车载组件的架构。不过，核心思想在于实际的应用程序，其中很大一部分在云端和边缘之间将是恒定的，或者保持一致的。 这意味着，当你在云端开发应用程序或服务时，一旦准备将它们部署到边缘，它们应该就能直接运行。正因如此，我们采用了容器等技术，以及编排等机制。这些技术在某种程度上借鉴了云端领域的实践，因此已经相当成熟。 人们对此已经很熟悉。我们需要做的，是让这些技术适应汽车行业的需求。这实际上意味着，我们必须考虑功能安全、实时性、异构计算等因素——这些在云端并不一定存在。因此，这正是SOAFEE将要应对的挑战之一。

SOAFEE 会员资格

罗伯特：所以，在过去的这几年里，我们实际上拥有一支相当优秀的成员队伍。你可以再次看到管理委员会的成员名单。 我们的会员数量目前已达到——我想实际上应该有115名左右。你们可以看这边，可能看不太清楚，但那是Sonatus 的标志。Sonatus 是SOAFEE的成员之一。这完全合乎情理，因为Sonatus 关注的重点很大程度上正是软件定义的车辆，也就是“云到车”技术。因此，他们是该领域的顶尖专家，我们完全可以与之合作。

SOAFEE 工作组

罗伯特：那么，简单介绍一下SOAFEE的组织架构。再次说明，我不确定这样解释是否足够清晰。我们有一个由AWS的比尔担任主席的治理机构。此外，我们还设有技术指导委员会和市场营销指导委员会。技术指导委员会主要负责统筹所有开展具体工作的技术工作组，其关注领域包括系统架构。我们正在研究云原生技术。 我们还在研究混合关键性，以及我们认为至关重要的虚拟机管理程序等技术。这些成果最终会融入我们发布的参考实现中，作为一种开源方式，让大家能够尽早使用SOAFEE。此外，我们还在开展其他工作。实际上，如果我们回过头来看，你会发现这边还有另一个“老虎团队”，那就是“蓝图老虎团队”。

SOAFEE 蓝图

罗伯特：所以，仅仅发布一个开源的参考实现虽然不错，但这在某种程度上还是依赖于人们主动去想：“好吧，现在我们得做点什么了。”对吧？ 因此，我们决定推出这些SOAFEE蓝图——这是一种参考应用程序，主要针对汽车领域的用例，并在SOAFEE环境中运行。它可以是开源的，也可以是闭源的。我们的目标是将示例应用程序引入SOAFEE生态系统供大家使用，同时也让OEM厂商能够借助现成的示例快速开展工作。 我将详细说明这些蓝图的具体作用。SOAFEE蓝图本质上是将参考实现运行在固件和硬件上所花费的部分时间进行优化。此外，我们还采用了容器化技术。正如我所说，SOAFEE架构的核心在于工作负载的容器化，即采用微服务架构。因此，不同工作负载会在不同的容器中运行。 你们可以看到这里的不同软件组件：既有特定于应用程序的工作负载，也有基础堆栈——其中包含容器、编排、可能还包括虚拟机监控程序、工具及其他所有组件。最底层则是计算平台。这就是通用蓝图的样貌。现在我将给你们举个例子。

Open AD Kit

罗伯特：第一个示例是一个名为“OpenAD Kit”的项目。该项目与一家名为Autoware的开源自动驾驶软件公司合作。我们在该项目中基本上是将Autoware的自动驾驶软件栈拆解为不同的容器，然后这些容器通过虚拟网络进行通信。因此，你可以看到每个容器中包含不同的功能：地图构建、感知、规划和车辆接口。 为了确保系统能够正常运行，我们起初稍微“取了个捷径”。实际上，我们在一个容器中运行了四个完整的Autoware实例，但其中仅启用了地图构建功能。 为了向微服务架构转型，我们需要采取以下措施：将每个功能分别部署到独立的容器中，这样就不再运行完整的自动驾驶栈，而是分别运行各个功能。这正是我们目前通过 OpenAD Kit 蓝图所做的工作。 蓝图的有趣之处——这也是我们开发它们的原因——在于我们希望行业能够采用这些蓝图，并开始将其作为示例：无论是作为原始设备制造商（OEM），还是作为其他科技公司，都可以借此展示其技术能力，让整个系统变得更加丰富多彩。因此，去年有一家名为Kern Concept的公司表示，他们打算重新研究这些容器化方案。 我知道其中一个功能——车辆接口——属于安全功能。如果它失效，车辆就无法运行。 明白吗？所以它应该在安全系统中运行。于是他们采取的做法是——如果我切换到这里——他们构建了两个系统：这边运行着大部分Autoware相关功能，那边则是负责安全功能的系统，主要运行车辆接口；并且在两者之间通过以太网连接，是真正的物理以太网，而非虚拟以太网。 这与容器化微服务的概念相同，但现在我们是在异构网络——异构系统中实现的。由此可见，安全部分位于这边，可以部署在安全微处理器上，本例中是恩智浦（NXP）的芯片。而这边则是应用进程，它们未必需要达到同等的安全级别。

SOAFEE 目标平台

罗伯特：说到平台，我们还需要做的一件事是搭建一些硬件平台——虽然地图上看不出来，但我们的许多半导体合作伙伴都是 SOAFEE 的成员。而我们目前真正努力的方向，就是让他们将各自的平台带进来。 将SOAFEE——即SOAFEE的参考实现——部署到这些平台上。正如你所见，我们有瑞萨（Renesas）、恩智浦（NXP）和Marvell等公司。我们还拥有来自AWS的原生云实例。这意味着，你可以在云端基于Graviton（一种基于Arm的处理器）上直接运行SOAFEE裸机系统。此外，我们也希望引入一些有趣的非汽车领域开发者平台。 因此，我们引入了Turing Pi和树莓派。事实上，在昨晚的COVESA活动上，树莓派正是运行SOAFEE的系统之一。好了，以上就是关于SOAFEE的介绍。

如何参与

ROBERT：如果您感兴趣并希望参与其中，SOAFEE.io 会为您提供大量信息。 我们有一个 Slack 频道，SOAFEE 也在 LinkedIn 上有官方主页。如果你想加入，最好的方式可能是直接联系我：Robert.Day@arm.com。我会协助你成为成员。这就是 SOAFEE。我们相信，这是将软件定义车辆变为现实过程中一个非常有趣的环节。 如果大家一直关注的话，会发现还有其他一些联盟也在致力于将软件定义汽车变为现实。但我们每个人都仿佛身处各自的领域，各自负责其中的一小部分。因此，这些努力如何融合在一起并不总是显而易见的。那么，这些努力究竟如何整合呢？于是，去年三月，我们决定也要尝试在这方面提供帮助。

SDV联盟

罗伯特：因此，我们组建了一个新的联盟。该联盟于昨日正式启动。这是一种合作——我称之为初期的合作——由四个组织共同发起，它们都致力于将SDV变为现实。其中包括Autosar，这可能是其中历史最悠久的……不，应该是最成熟的联盟。 还有COVESA，它以前叫GENIVI或GEN IVI。还有Eclipse SDV，以及SOAFEE。因此，我们正在推动这些不同联盟之间的合作。可以说，这就像是“联盟中的联盟”，或者如果你愿意，也可以称之为“合作中的合作”。 仅就这四个组织而言，就有超过500家汽车生态系统企业参与了这些不同的联盟。这不仅带来了什么，也是我们作为联盟将要做的事情，就是非常明确地说明这些元素如何相互契合。实际上，在昨晚的启动活动上，我们演示了这些联盟各自部分的协同运行，以此展示并证明这是可行的。 但这确实将云端到边缘、联网汽车、开源技术、开放标准以及实时处理与安全等要素整合到了一起。我们的目标是，如果能真正做好这一点，将使整车制造商在开发和部署软件定义汽车时的工作变得更加轻松。同时，这也将促进合作，推动更深入的合作。 不是那种各自为政的联盟式合作，而是真正意义上的携手共进。过去九个月里，我们致力于组建这个联盟并开展合作，这段历程非常有趣。现在联盟已经正式启动，工作才刚刚开始。所以我想说的是，请大家密切关注联盟将推出的各项成果。再次强调，如果您想参与联盟，可以联系其他任何一家成员组织。 最后我想强调的是，这是一个开放的联盟。我们期待其他联盟也能加入进来，这不仅仅是我们四家。我们希望以此为起点，同时也鼓励其他联盟参与到这个联盟以及这项联合行业行动中来。我们深信这一点——昨晚我与两家整车制造商交谈时，也听到了他们对此的赞赏。 因此，我们希望这将成为一个非常好的开端，真正开启软件定义汽车的征程。我之前提到这一进程已经启动，但我们需要做的是将其真正推向大规模应用。我们希望所有联盟成员能够齐心协力，共同努力，让这一愿景成为现实。让我们跳过这一张幻灯片。

结论

罗伯特：那么，借此机会，我想表达一下感谢。再次感谢Sonatus 给我们这个机会，让我们能来这里分享这些关于软件定义车辆的精彩内容。希望各位在线观看时能有所收获。非常感谢。