云计算在当今汽车中的作用（第二部分）

概述

约翰：今天在《The Garage》节目中，我们将带来关于汽车云计算的特别两集系列节目的第二集，本期特别嘉宾是来自AWS的斯特凡诺·马尔扎尼。在第一集的对话中，我们探讨了云计算在数据和计算方面的内容。在本期节目中，我们将继续这一话题，讨论原型设计、数据分析、AI ，以及云计算在ADAS和自动驾驶领域的应用。让我们继续与AWS的斯特凡诺·马尔扎尼的对话。开始吧！

主题 3：云端原型设计与“环境等效性”

约翰：其实这正好引出了我们的第三个话题——原型设计。正如我刚才提到的，我们最近与罗伯特·戴进行了交流，Arm发现其架构正在被应用于汽车中的众多子系统。你知道，我在Arm工作了14年，对此我感到非常自豪。所以这个话题对我来说意义非凡。罗伯特也对此谈了很多。 但我认为这也意味着——我想这也是你提到的观点之一——Graviton 部署在云端，云端拥有基于 Arm 的实例，同时汽车中也有基于 Arm 的实例，这为原型设计解锁了一些非常有趣的潜在可能性。

斯特法诺：没错，确实如此。 我们称之为“环境一致性”，对吧？我们最早是在2021年的Arm开发者峰会上开始使用这个术语的。当时我们在峰会上举办了一场研讨会，该概念在业界获得了相当广泛的传播和关注。因为那是我们首次提出这一概念：既然汽车中运行的软件基于Arm架构，那么为什么不能在云端使用Arm架构来运行相同的软件呢？ 是相同的Arm架构，但并非相同的处理器——我们既不知道，也没有打算将Graviton芯片用于汽车，对吧？实际上，汽车电子控制单元（ECU）来自高通、英伟达、恩智浦等多家供应商，它们全都基于Arm内核。而且，这些Arm内核与我们Graviton中使用的内核完全相同，对吧？ 至于ARM 64，当然，这并不是同一款CPU，因为我们的Graviton基于Neoverse架构，而汽车中通常采用Cortex架构，但指令集的大部分内容是相同的。

在云端和车载环境中运行 Arm 系统

斯特法诺：这就是我们能够实现加载的原因，而且在想到这个点子后，我们就付诸实践了。因此，现在我们拥有种类繁多的嵌入式操作系统——这些系统过去通常只在模拟环境或物理硬件上运行，对吧？——如今却能在AWS云端的Graviton上原生运行。 比如QNX、VxWorks、Yocto Linux、AGL等系统。对于嵌入式开发者来说，这是一种全新的开发方式，我们收到了令人难以置信的反响——甚至可以说有些出乎意料，他们惊呼：“等等，这只是在云端启动这个进程，而我面前竟然出现了QNX提示符，简直就像在操作一个ECU一样。” 是的，这正是我们所说的“环境一致性”。你可以在那里开始工作。虽然你还是需要硬件，但并非为了启动开发。

在云端开始软件开发

斯特凡诺：这目前是该行业的一个巨大瓶颈，从原型设计的角度来看也很重要，对吧？如果你总是需要开发人员——尤其是更优秀的开发人员——拥有硬件来工作，那么你就只能依靠低端创新，对吧？因为目前没有硬件能满足这一需求。

约翰：当然。 从测试的角度来看，就是回归测试。我们在之前的节目中提到过，我们也开始采用基于云的方式进行测试了。因此，与其拥有一排排需要远程重启的系统，不如使用虚拟实例和EC2。我们现在也在这么做。我们看到了这种优势，并且正在广泛应用这一方式。

汽车领域的验证难度

斯特法诺：是的。是的，绝对是。这，这对于开发人员来说，以及在验证阶段，确实是一个巨大的优势，对吧？ 想想看。即便在今天，汽车实际上仍是一个尚未经过深度测试的系统。这主要是历史原因造成的。正如我们在本期节目开头所提到的，汽车正经历着一场深刻的转型——从现代内燃机车辆中由150多个ECU组成的系统，转变为由30、40个左右、集成化计算机组成的、数量大幅减少的系统。 虽然仍会有基于微控制器的外围单元用于传感或执行，但主要计算将由集成架构来完成——这些架构中包含多个Arm内核，可能是8个、12个、16个甚至40个，对吧？这是一种高度集成的架构。这一点非常重要，对吧？这确实是一个极其重要的趋势。

通过云技术赋能开发者

斯特凡诺：而且不能指望开发人员把这些设备放在办公桌上进行开发，必须为他们提供一个环境——一个云原生环境，原因正如我们之前所见。因为那里有数据，有计算选项，还有Graviton。因此，这才是开发人员可以自然而然地找到所需工具、开展工作、在硬件上部署并持续进行硬件测试的环境，反之则不然。

未来五年内，车载软件的数量将增长两倍

斯特法诺：因为如果从硬件入手，创新就会被扼杀。你知道，据一些分析师预测，在未来五年内，软件定义汽车（SDV）的代码量预计将从1亿增至3亿，增长三倍。如果仍然要求开发人员依靠硬件来开发和编写汽车代码，又怎么能实现这一目标呢？

约翰：哇，这数字太惊人了，我之前还没听说过这个统计数据：未来三年内要翻三倍？

斯特法诺：五年。

约翰：太不可思议了。你知道吗，我一直在想，我觉得这里也存在一个良性循环，因为我们在之前的某一期节目中讨论过工作负载的整合，你刚才也提到了这一点。而且，我们还谈到了虚拟化的重要性，以及能够让这些应用程序并行运行却互不干扰的能力。 在我看来，这与云原型设计方法以及虚拟化之间有着很强的协同效应，因为你可以将之前在那里测试过的相同工作负载，现在让它们并行共存。而且，正如你所说，这与你所提倡的“环境一致性”方法非常相似。

斯特法诺：是的，绝对是这样。绝对是这样。而且，再想想看，当你开始拥有12个、16个内核时，不会把它们全都用于单一操作系统，这意味着你需要将这些内核进行分区，并运行多个操作系统。 但这正是我们在云端所做的：我们有一个虚拟机管理程序，它能在Graviton处理器的64个核心上管理多个操作系统，对吧？这完全是一样的。当然，在电子认证以及许多其他方面，两者是不同的。但从软件工程的角度来看，我们可以采用一种方式，使这两种环境非常接近。

约翰：所以，在原型设计和测试阶段，这几乎是在验证它最终实现时会是什么样子，这非常有趣。这……这让我着迷，从技术角度来说非常着迷，而且我认为它作为开发工具也非常强大。

通过“左移”加快设计周期

约翰：而且，你知道，正如我们之前讨论过的，早在几年前我们就关注过“左移”这一理念——即如何利用虚拟原型设计、云技术等手段来加速设计周期。正如我们在最近的一期节目中也提到过的，设计周期正面临着加快速度的压力，我认为整车制造商（OEM）和一级供应商所处的竞争环境正变得日益严峻。 如果这些技术能缩短设计周期，就能提升企业的竞争力、降低成本，而且——正如你所说，随着软件代码行数的增加，这种复杂性确实需要有效管理。我认为必须采取“分而治之”的策略才能实现这一目标。否则，如果将其视为一个庞大而单一的系统，就根本无法进行验证。

汽车召回导致400亿至500亿美元的损失

斯特法诺：绝对是。此外还有其他优势。所以，毫无疑问要推行“左移”。代码质量会得到提升，因为你可以更广泛地扩展测试范围。这一点绝对非常、非常重要。 试想一下汽车行业的情况。时至今日，我们每年因召回造成的损失仍高达400亿至500亿美元。其中70%归因于软件故障——这是已记录案例中的70%。请仔细想想这一点。这质量太差了，我们能这么说吗？

约翰：是啊。

斯特法诺：测试效果不佳。

约翰：当然了。

斯特法诺：不是向左移动。

约翰：是啊。

斯特凡诺：对吧？所以向左移，既能降低成本，又能提升质量。但我还想考虑一下最终用户。因为我们看到的是，如果不需要将这些电子控制单元（ECU）送出去开发，就可以在云端实现协作。这一点非常重要。事实上，这是软件定义车辆（SDV）的一个令人惊喜之处。我们讨论了基于车联网（telematics）的ADAS/AV服务，也就是车联网服务。

利用云技术开发车载人机界面

斯特法诺：我们看到云端的人机交互（HMI）开发——包括人机交互、用户界面和用户体验——呈现出巨大的增长。对我来说，这简直太棒了。你立刻就能明白其中的原因。 你之所以能明白原因，是因为我们首次在云端拥有了一个虚拟ECU，它能在浏览器中呈现用户界面。由于云服务覆盖全球，我可以立即将其展示给遍布世界各地的协作网络中的所有成员。因此，我可以询问日本或南非的同事：“根据你们当地的审美习惯，你觉得我这个新用户界面怎么样？你能对其进行适配吗？或者你能参与改进吗？”

约翰：还有本地化和语言。

斯特法诺：这简直是人机界面（HMI）系统开发方式的一场革命——试想一下，不再需要到处部署硬件，而是采用我们所说的“云原生、云优先”的HMI开发方法。我们已经有一家客户正在尝试采用这种方法。 此外，我们最近还与宝马合作，在柏林举行的上一届AWS峰会上发布了一场非常有趣的演讲，介绍了他们在云端开发HMI的实践，当然我们可以提供相关资料。这是一次精彩的演示。但我们并不总是只谈宝马，例如，我可以谈谈我们在CES上与马瑞利（Marelli）共同展示的演示。马瑞利是一家一级供应商。 他们在我们的展位上展示了首个云原生 HMI 系统。这真的很棒，因为你可以看到我们是在云端开发 HMI 应用程序，然后部署在意大利的米兰。当时是一位工程师在云端完成开发，随后将其部署到拉斯维加斯的展位上，对吧？同样，你从云端开发开始，然后在特定的硬件解决方案上进行部署和定制，对吧？ 仔细想想，这真的、真的非常强大。这不仅仅是有能力，这就是SDV，对吧？它是软件定义的。否则，如果从硬件开始，那就是硬件定义的。如果真的是软件定义的，就必须从软件开始，之后再进行部署。

SDV 可降低召回成本

约翰：没错，没错。你刚才提到了很多方面。我觉得我不该忽略你提到的关于召回的那一点。 我们经常听到原始设备制造商（OEM）表达的担忧——他们确实面临巨大的软件开发负担，他们会说：“哦，要实现这种软件定义的车辆功能太难了。”但当你考虑到这个数字时，就像你说的，400亿、500亿美元，其中很大一部分都与软件相关。如果不具备应对这些挑战的能力，那简直是疯狂的，因为只需投入很少的资金，就有可能节省数十亿美元。

斯特法诺：是的，我们和康迪公司的马丁·施塔姆一起录制了一期非常精彩的《汽车万象》节目。

约翰：是的，我看过那一集。

斯特法诺：是啊，你看到了吗？就是他解释为什么会那样的地方，对吧？

ECU的整合

斯特法诺：传统上，制造商（OEM）总是有必要集成新功能。这意味着，好吧，我们需要再集成一个ECU，再一个，再一个，直到达到150个。但如果你考虑一下这种组合效应，你永远无法测试所有可能的组合情况。 正因如此——这对整个行业来说是件好事——在电气化及其他趋势的推动下，著名的CASE（互联、自动驾驶、共享和电气化）概念，再加上用户体验，这种整合正在发生。

在不增加冗余的情况下有效整合软件

斯特法诺：说实话，这对整个行业来说确实是个福音——毕竟问题在于如何将分布式系统中的软件进行改造，并将其整合到这些整合单元中。但是，这里有个“但是”，因为关键在于不能仅仅说：“好吧，现在这个ECU里的软件我直接拿过来，塞进我的整合单元就行了。” 那叫臃肿软件。你知道，它随时都可能“爆炸”。你必须重新设计系统架构，因为整合单元与经过成本优化的单个ECU有着本质区别。而且从资源角度来看，其中的软件原本就是专门为那种近乎定制的硬件设计的。 这就是为什么我们看到这么多——你也清楚这一点，对吧？——比如我们与Autoware基金会合作开发的Open AD Kit项目，旨在将自动驾驶领域的软件（这种软件传统上属于单体架构，也就是我们所说的“单体”）拆解为微服务，并重新架构，使其能够由真正需要更高模块化程度和更强灵活性的软硬件平台来支持。 增量更新，对吧？接口的标准化。所有这些都是重构整个汽车行业架构至关重要的概念。

SOAFEE 与汽车行业标准

约翰：你知道吗，你刚才提到的内容与我们最近和罗伯特·戴关于SOAFEE的讨论有着很强的协同效应。关于SOAFEE，我知道亚马逊是该组织的创始成员之一，所以你们对此非常支持。该项目很大程度上正是致力于提供你提到的那些标准和一致的接口。不过，也许这个话题留到下次再聊吧。

斯特法诺：是的，完全同意。顺便说一句，这是一场内容非常丰富的讨论，我认为SOAFEE是一项非常棒的倡议。如果你了解过，SOAFEE旨在基于开放标准和开源技术提供一个参考实现。 哎呀，汽车行业确实非常需要开放标准和开源技术，对吧？所以像Yocto、COVESA、Eclipse SDV、AUTOSAR这样的倡议才显得尤为重要。而我们在SOAFEE中观察到的一个非常积极的信号是，我们开始通力合作了，对吧？我们必须坚持这一点，对吧？ 确实，因为开放标准是关键，你不会在标准层面进行竞争。那是不可能的，对吧？真正的竞争——当标准定义完成后——才开始，你可以针对客户真正、真正需要和想要的东西进行创新，而这些恰恰不在标准范围内。如果有人说“啊，是的，我要买这辆车，因为这个标准被完美地实现了”，这根本说不通。对吧？

约翰：没错。关键是要在标准的基础上实现增值差异化，但要以标准为基础。

斯特凡诺：作为基础。没错，说到底，这也是节省成本、实现优化的另一种方式。毕竟，为什么要花时间和金钱去在一种大宗商品功能上寻求差异化呢，对吧？

约翰：如果到目前为止你喜欢这一集，我诚挚地邀请你为本期点赞，并订阅我们的频道，以便在《The Garage》中观看更多内容。我们大约每两周拍摄一集，期待你在下一集时再次光临。

主题 4：机器学习与分析

约翰：斯特凡诺，我们已经讨论了许多不同领域，接下来我想谈谈人工智能、机器学习，以及更广泛意义上的数据分析，因为我们谈到了我们收集的这个令人惊叹的数据湖，也谈到了你们在专业计算服务中提供的各类专用计算类型所具备的计算能力等等。 还有原型设计的重要性等等。但机器学习和分析这一整个领域或许是最引人入胜的，它们的结合能够实现前所未有的突破。

斯特凡诺：绝对没错。而且这始终要从我们所说的“大循环”的角度来考虑，对吧？这一点非常重要，因为你听得没错，科学家们经常说，在构建正确的模型时，数据集是最重要的，对吧？所以，在这一点上，我们始终以此作为参考。因此，要选择合适的数据存储在云端。

使用 SageMaker 进行数据采集和标注

斯特法诺：所以，我们需要在汽车中加入一点人工智能，以便根据具体情况判断哪些信息是相关的，对吧？也许你曾紧急刹车过。那么原因是什么呢？或者说，这可能是多种因素综合作用的结果。还有车载测试，我们现在就来讨论这一项极其重要的功能。 不过话说回来，在数据筛选完成后，其中涉及的机器学习模型本身也需要定期更新，对吧？我们发送数据、收集数据、清理数据、整理数据湖，一切都很完美。然后，我们利用其中一部分数据对另一部分数据进行标注，对吧。 因此，我们的客户会根据自身需求对数据进行标注，我们提供了一款名为SageMaker Ground Truth的工具来完成这项工作。当标注完成后，我们便利用这些标注数据来训练和验证模型。在此过程中，我们有多种选择。SageMaker正是我们用于实现这一目标的平台。

AWS 中的其他机器学习框架

斯特法诺：如果你真是机器学习领域的深度专家，你可以使用像PyTorch这样的基础框架，真正深入到底层；或者，你也可以使用我们所说的AI 服务。比如图像识别服务——你只需发送一张图片，就能得到其中的物体列表。没错，还有AI 等转录服务。因此，我们有这三个层次。

新模型的车载验证

斯特凡诺：当你通过 SageMaker 训练模型时，通常会将其部署到边缘设备上，但这又是一个循环过程。也就是说，模型虽然已部署，但尚未投入生产环境，目前仅用于车载测试。 该软件还有另一个版本目前已投入生产。因此，第一阶段是分析该模型相对于已投入生产的版本，其性能是更差还是更好，将其置于真实环境中进行测试，可能涉及大量实际车辆，因为我们受限于计算能力。不过我们还有一些额外的计算资源，可以在那里进行更多的计算。

查找边界情况

斯特法诺：没错，正如你之前所说，这样做是为了什么呢：就是为了找出那些特殊情况，也就是所谓的“边界情况”。仅凭抽象的设想，在开发初期根本无法预见这些情况，你确实需要有实际车辆——而且是大量车辆——才能对机器学习模型的性能进行验证。 而在评估过程中，如果确认模型表现更优且没有退化，你就切换到新模型，将其投入生产，这个循环就这样持续下去，对吧？ 而且是在越来越多的车辆上进行验证，对吧？由此可见，机器学习绝非仅仅是一种神奇的训练方法，而确实是一个智能的循环。定义工作流非常重要，我们拥有许多工具来管理这些工作流，其中一些就集成在SageMaker本身中。

用于管理机器学习工作流的工具

斯特法诺：还有其他一些工具，例如在数据管理方面，我们提供 Airflow 的部署和管理服务，这被称为“基于 Apache Airflow 的托管工作流”。我们利用它来构建所有这些工作流，对吧？我在之前的工作中就用过 Airflow，它非常强大，能够构建这类管道。对吧？这是其中非常、非常重要的一部分。 所有这些，我们的客户通常会在所谓的“工作台”中使用，对吧？越来越多的客户要求我们提供一个浏览器端的工作空间，让他们能够在此找到所需的工具。这些工具可以是数据管道、工作流、与机器学习相关的数据、数据湖访问权限，以及行业专用工具。例如，就在最近，我们在dSPACE活动上展示了一项与MathWorks的合作方案，该方案正是基于此类工作空间的构建。 因此，您可以在该空间中找到这些工具。这样一来，您不仅能够高度聚焦，还能确保环境的一致性、实现环境的全球部署、对这些环境的全球访问，以及集成和创建自动化流程的可能性。 最近，我们的首席执行官在LinkedIn上发文称，丰田采用这种方法每年节省了1000万美元。这效果相当不错，对吧？仅仅是把工具整理好，通过一个通用界面呈现，并能据此创建自动化流程，就已如此显著。

约翰：我觉得你所说的有趣之处在于，其中包含了几个不同的方面：首先是从数据入手，即原始数据，然后具备建模、调优和改进模型的能力。接着，在云端，各种不同的工具和模块可以相互连接，从而进行后处理和后续分析。这类工具和模块种类繁多。因此，我认为整个这个循环非常重要。

斯特法诺：绝对没错。正因如此，例如，我们通过自主驾驶数据框架（这是一个开源项目）组织并公开了相关内容，旨在向客户提供开源参考资料，以便他们能够构建此类架构和工作流。 而且，诚然，我们的客户确实大多正是以这种方式采用这些工具的。以丰田这样的客户为例，他们利用我们的P实例连接到我们的计算环境和协作平台，在AWS上训练模型。但需要强调的是，这绝非孤立的单一活动，而只是工作流中的一部分。这一点非常重要，必须予以考虑。

主题 5：ADAS 与自动驾驶

约翰：也许现在正是转入最后一个话题的绝佳时机，那就是ADAS和自动驾驶——这是我们曾共同致力于研发数年、积累了丰富经验的领域。 让我们来谈谈云计算对ADAS发展的重要性——我认为它是不可或缺的——以及它对我们所有人正在踏上的通往自动驾驶的这段征程所蕴含的潜力。这确实是一段漫长的旅程，但我们正在稳步前进。

斯特法诺：绝对没错。而且，正如我之前所说，我对此充满热情——我们之前也已经就这一点展开过讨论——我非常热衷于为自动驾驶、自动驾驶功能以及普通车辆的自动驾驶能力提供一种渐进式的发展路径，对吧？

ADAS带来的短期效益

斯特法诺：因为现在ADAS系统——比如L2、L3，也就是所谓的二级、三级自动驾驶——能带来巨大的价值。这一点非常重要，因为首先，它们能拯救生命。道理就是这么简单。对吧？所以，我们最近测试了一款搭载最新一代ADAS系统的汽车，表现非常出色。 这辆车确实配备了自动紧急制动系统。例如，如果你分心了，而前方出现障碍物，车辆就会自动刹车。虽然原理简单，但只要能正常工作，就能挽救生命。所以对我来说，这是极其重要的一环。而且我越来越确信，自动驾驶将是由这些功能组成的集合，这些功能会逐步实现自动化，对吧？ 因此，除了这些功能之外，还要考虑车辆中将逐步实现自动化的增量功能，这一点也很重要。这就是我的观点。至于我们构建云平台的方式，再次强调，利用我们之前讨论过的所有内容——本质上包括多种计算选项、数据湖的构建可能性以及机器学习工具——这些都是ADAS和自动驾驶汽车开发所必需的基础要素。 关于计算选项还有另一个方面，由于两个与ADAS密切相关的特定原因，这一点非常、非常重要：通常情况下，您会从现场收集数据，并将数据存储在S3的数据湖中。然后将其用于验证，对吧？因此，您通常会将从车辆收集的数据回放至正在开发的算法中，以评估其性能是优于还是劣于上一代算法。 或者，您也可以利用计算资源进行合成仿真。我们与法雷奥（Valeo）合作过一个非常精彩的用例，原本计划在因新冠疫情而取消的CES展会上展示——虽然很遗憾展会最终无人参与，但我们准备了这场精彩的演示（YouTube上有视频，当然我们可以提供链接），其中您可以看到法雷奥利用两项技术：一项是IPG CarMaker，另一项是Foretellix，用来 通过合成仿真来成倍增加场景数量，并在AWS上将场景扩展到数千种不同的变体，因为AWS具备可扩展性、计算资源的弹性以及计算资源的高可用性，从而真正尝试覆盖所有这些边界情况，本质上就是为了探索我们的分析中是否遗漏了什么，对吧？

寻找边界情况

斯特凡诺：并且要努力实现“左移”，正如我们之前讨论的那样，在软件部署到车辆之前就解决这个问题，对吧？所以，归根结底，这还是一个重新构建这些工作流的问题，而在 AWS 中，我们拥有所有必要的工具来帮助客户实现这一点。如果没有，我们也乐意与客户合作来创建这些工具。

自动驾驶的分解

约翰：绝对是。我觉得很多人可能认为自动驾驶是一项整体性的任务。但实际上，它包含许多、许多子任务。我常开玩笑说，有自行车识别任务，还有车道保持任务。不过玩笑归玩笑，子任务确实多种多样。你必须把这个任务分解开来——你知道，我们开车时，只是开着车，仅此而已。 但实际上，机器学习和人工智能的做法就是将其分解为不同的部分。你刚才提到的这一点，我觉得非常有趣。因为当你考虑训练时，想想人类驾驶的情况，大多数时候其实相当无聊，就是一直笔直地开，很乏味。 所以，比起那些必须反复练习的情况，真正的难点在于：虽然可能会遇到急转弯或障碍物，但你提到的观点非常有趣——你可以加速模拟极端情况，提供大量极端案例，从而帮助模型比在真实驾驶场景中学习得更快。

斯特法诺：绝对没错，绝对没错。这完全正确。正因如此，比如我们之前讨论过的，从这个角度来看，微服务非常重要，因为你可能只想替换感知模型，而让其余部分保持不变，对吧？所以需要由拥有不同技能的团队，各自负责自己那部分工作，对吧。 因此，这非常关键——要认清ADAS或自动驾驶汽车开发中存在的不同角色。这确实至关重要，对吧？确实，这是一个复杂的场景。但话说回来，我们在这方面有非常好的参考案例。我之前提到的与大陆集团的合作案例就是ADAS开发，你会真切地看到，在采用云原生方法时，他们在节省时间、降低成本和提升敏捷性方面获得了怎样的收益，对吧？ 这正是我们与他们共同开发的CAEDGE演练的初衷。顺便提一下，那也是在“软件定义车辆”的实践框架下进行的。因此这是一个极好的参考案例。我们与大陆集团的合作，正是我们开始思考这些架构概念的起点。可以说，这是一次非常出色的合作。

AWS 与……之间的合作Sonatus

约翰：作为本次对话的总结，我想我们不妨花一点时间谈谈Sonatus 和AWS在哪些领域展开了合作。

斯特法诺：是的，非常乐意。毕竟，我在车库里看到了一些令人惊叹的演示——顺便说一句，非常感谢你向我展示了这些。 那些功能简直太棒了，对吧？比如我看到的一些功能，例如控制车辆的逻辑，以及根据新情况部署新逻辑，这完全符合我们之前讨论的关于SDV（软件定义车辆）和大循环更新的内容。所以你真的能看到这些正在实现。看到这一点真的太棒了。是的，这是一次很棒的合作，也是一个完美的范例。 你看，这不仅仅是发送或收集数据，而是开始实现这种数据平面（data plane）的构想——没错，我们需要收集数据，但控制平面同样重要。因此，要管理这种从云端到边缘再返回的微逻辑，你必须具备一些这类微逻辑，也许在边缘部署一些机器学习，同时还需要在云端运行这些微逻辑或机器学习。 再谈及整合，尤其是Arm内核，这正是我们所说的从云端到边缘的连续体。我认为，你们通过这一系列产品，在实现这一愿景方面确实做得非常出色。

约翰： 你知道，非常感谢。我们之前谈到了数据，我们的Collector产品经过高度优化，它能够收集、调整并精心筛选高价值数据，然后将其发送至云端，目前我们正在这方面与你们合作。至于你刚才提到的Automator产品——我们最近刚刚推出——它让我们能够将“智能数据”这一理念付诸实践，进而采取相应行动，无论是车内还是车外的行动。 我们之前并未详细讨论车辆测试，但车辆测试的问题也正变得日益复杂。因此，我们很高兴能够以新的方式利用这项技术，例如优化生产工作流程，并提供更优质的下游服务。您之前提到了联网汽车，以及面向用户的下游能力，甚至包括下游的增值服务提供商。

使用真实ECU的重要性

斯特法诺：是的，这确实很有意思。而且我注意到这又是一个非常好的观点，因为你们是在真实的ECU上进行测试的。 相信我，这其中的差异非常巨大，因为我总是说，你知道，当你为汽车开发新的软件组件或硬件组件时，其中50%是开发工作，50%是V和V（验证与确认）。以ADAS和AV为例，我们来做些假设。ADAS方面，我认为大概是20:80的比例。 而在自动驾驶领域，这个比例则是1:99。对吧？因为实际上，当你开始看到代码在真正的CPU上运行时，你会发现情况截然不同，对吧？这已经不再只是基于评估套件、摆在你桌上的原型机了。而是要部署到100万辆、200万辆甚至1000万辆汽车中的系统。所以这完全改变了局面。

约翰：你说得对。而且我们非常高兴能参与其中——你知道，到今年为止，我们的技术将应用于数十款车型，到明年年底，将覆盖数百万辆汽车。看到这一幕真的很令人兴奋，这已经不是原型机，也不是科研项目，而是真正的量产。 而且从真正的量产中能学到很多东西——正如俗话所说，这才是真正的实战。这也让事情变得更加艰难。

斯特凡诺：是的。 而且任何从事汽车行业的人都知道，为了符合法规要求所付出的努力。这可是该行业的重要组成部分，对吧？所以你不能像在手机上那样随意部署代码。对吧？这可不是消费类设备——从某种意义上说，它是一种受监管的产品，涉及功能安全，还涉及网络安全。这些方面至关重要，对我们来说也极为重要。这是头等大事，是“零级优先级”。

摘要

约翰：是的，今天我们谈到了很多内容，光是刚才提到的那些子话题，就足以展开许多场各一小时的讨论，但今天我们不得不就此结束了。首先，斯蒂法诺，非常感谢你今天能来。很高兴你能来做客。 今天的对话让我受益匪浅，我总是很享受与你交谈，希望你能再次光临。

斯特法诺：我也是，谢谢邀请。每次来都很开心。我自己也学到了很多。太棒了。

约翰：谢谢，斯特凡诺。在今天的节目中，我们探讨了云计算的方方面面，特别是从 AWS 的角度出发，讨论了云计算如何为汽车行业和车辆工作流带来益处并加以优化。我们首先从数据入手，探讨了数据的重要性及其多种应用方式；接着讨论了计算能力以及对各类计算服务的需求，这些服务能够解决不同类型的问题。 我们探讨了原型设计，特别是能够在云端对车辆功能进行原型设计并部署到实际车辆中的能力，这一点非常令人信服。我们还讨论了机器学习和数据分析，以及如何通过数据分析以多种方式创造价值。最后，我们简要谈到了自动驾驶和ADAS（高级驾驶辅助系统），以及改进和优化这一流程的重要性。这是一次内容广泛的对话。 希望您喜欢本期节目，我们期待很快在《The Garage》的下一期节目中与您再会。非常感谢。