SDV带来的意外挑战

‍‍如果你经常关注行业新闻，或出入各种论坛，那么你一定会觉得软件定义汽车（SDV）绝对是当下的流行趋势。

CMU（Carnegie Mellon University）教授Phil Koopman最近发表了一篇题为的文章，表达了审慎的态度。

尽管这篇文章的标题很有煽动性，但Koopman也说到，“我认为SDV并没有真正死亡。”

然而，当车厂们冲向SDV的悬崖时，Koopman警告说，他们可能会把汽车架构拼凑在一起，而这些架构不可避免地会变得过于复杂，难以管理。

Koopman解释说，SDV的承诺是让汽车设计师能够“将所有功能集中到一个大盒子里（或是一组中型大盒子）”。“随着高带宽网络的出现，各种功能现在都可以在共享硬件上争夺资源”。

从表面上看，很多人会认为新架构中软件和硬件的更高集成度是个好主意。既然Tesla已经做到了，其他公司还在等什么呢？

这正是Koopman不同意的地方。他认为，SDV的基本架构原则“更高的内聚性（higher cohesion）”（类似的功能放在一个盒子里）和“更低的耦合性（lower coupling）”（进出一个盒子的几种定义清晰的数据类型），促使设计师开发出更好的架构，但随着SDV的出现，这些原则可能会消失。

Koopman认为，车厂最终可能会“淹没在复杂性之中”。

他告诫说：“任何研究系统架构的人都会发现，我们在SDV中看到高耦合（可能是低内聚）的系统并不奇怪。”他预测，这将“伴随着惊人的失败”。

我几乎能在脑海中听到汽车和电子行业的一片哗然，呐喊着“不要把孩子和洗澡水一起倒掉”。

但是，Koopman的警告是有说服力的，也是及时的。

事实上，他的评论不禁让人停下来思考：一个主要以硬件定义其产品的行业，如何在几乎一夜之间掌握软件技能，并避开通往SDV道路上的所有坑？

我们已经看到因软件缺陷造成的汽车召回数量激增。其他广为人知的例子还包括一连串灾难性的软件故障，这些故障令车厂们头疼不已。

大众及其软件子公司Cariad就是其中之一。据瑞典刊物Carup报道，Volvo的旗舰车型EX90也遭遇了“公司历史上最大的软件开发失败”。该报道指出，EX90的开发在五年内经历了四任经理，“软件仍然缺乏重要功能”。

如果Koopman的观点是正确的，那么考虑到车厂迄今为止尚不可靠的软件技能，SDV的出现更有可能加剧而非简化开发过程。

尽管越来越多的车厂选择了OTA，但这仅仅是SDV开发的起步阶段。SDV并不是OEM可以从Tier 1那里购买的插件。它是一项需要设计人员长时间认真思考SDV应该做什么、应该是什么样子，以及如何架构的技术。这就是为什么Intel的汽车事业部副总裁Jack Weast曾说：“SDV不是一种功能，而是一种思维方式。”

要真正实现SDV，需要进行更艰苦的讨论。

Capgemini的题为的报告指出，软件将推动汽车行业的变革。然而，一个更大的问题是，车厂能否应对SDV带来的意外复杂性。

我们都在各种文章和PPT中看到过SDV概念图，图中往往点缀着域控制器或zonal ECU盒子，有时还会加上一个大CPU。

从架构上讲，“内聚性”的关键在于每个盒子内部集成的功能。Koopman打了个比方，将一栋完全由住宅单元组成的公寓楼与一栋包含超市、餐厅、公寓、车库等的综合性建筑进行比较。他解释说，与同质化的纯住宅楼相比，混合用途建筑的内聚性较低，“这可能有一些优势，但维护和管理起来更加复杂”。同样，“内聚性”在车辆架构中也很重要。关于这个基本问题的讨论，即哪些“相似”的功能集成在哪些盒子里，还很少开始。

投入更多技术‍‍

对已知的技术问题（如SDV）投入更多的技术通常是技术界的简单做法。

例如，如果车辆缺乏进行AI或传感器融合的处理能力，那么我们就引入一个更大的SoC，它可以实现更高的TOPS。车载网络带宽不足？引入车载以太网。

问题的关键在于，这种做法会成为很好的头条新闻，将芯片塑造成解决车厂SDV问题的英雄。但仔细观察就会发现，在实际简化SDV的基本软件和硬件开发流程方面进展甚微。

Volvo EX90的惨败就是一个很好的例子。

Volvo EX90本应“在Nvidia Drive Orin平台上开创AI时代”（Nvidia于2022年发布的新闻稿）。不幸的是，由于没有开发“中央计算”技术的经验，Volvo想不出如何利用Orin。根据Carup 的报告，Volvo“有100多人参与开发工作，但进展缓慢，错误百出”。“问题在于有多个内核可以相互通信。Nvidia以外的工程师几乎不可能调试芯片。”

投入更多的软件工程师‍‍

另一种解决SDV设计问题的流行方法是大量增加软件工程师。汽车或电子行业的公司都会炫耀自己最近招了多少软件工程师。

Koopman说：“是的，如果你愿意，你可以大量招聘软件工程师。”他提出的注意事项是，汽车行业需要的软件工程师并不一定是那些擅长敲代码的人。

Koopman指出，“称职的软件工程师”必须能够“以合理的方式将大块（软件）分割成小块，界面整洁”，并“指定界面”。他们应该能够“审视依赖关系，管理和分配需求，寻找不一致和冲突”。

Koopman说，在他的软件工程专业学生中，那些想在FAANG（Facebook、Amazon、Apple、Netflix和Google）等公司寻找薪酬更高的工作的学生，更喜欢去在线平台LeetCode为编程面试做准备。从本质上讲，学生们被激励去写代码，而不是去思考SDV开发所带来的架构难题。

Koopman在最近接受采访时说：“如果下一代软件工程师没有做好准备，无法应对SDV等技术带来的尚未预见的问题，那么作为教育机构，我们是失败的，作为社会，我们也是失败的。”

组织问题‍‍‍‍

最后，横亘在汽车系统设计师和SDV架构开发之间的，莫过于他们所服务的组织。

S&P Global Mobility汽车部门副总监Phil Amsrud说，一个挑战是“如果你将SDV发展到极致，你就会将所有东西都集中到一个大的中央计算机中，由它来完成汽车上的所有系统”。

但问题是，Amsrud指出，“有哪个OEM的组织架构是这样的”？

传统上，OEM的组织架构是各自独立的，如动力总成、底盘、信息娱乐等。

SDV带来了令人生畏的技术问题，但同样重要的是组织和文化难题。

Amsrud说，所有现有车厂面临的一个开放性问题是：“如何打破现有的组织架构，让这些不同的部门比以往更加开放合作？”

这让我想起了大众最近宣布与Rivian的合作。理论上，他们可以将Rivian的工程团队与大众的团队合并。但如果给他们一个deadline，让他们共同开发一个SDV平台，会发生什么呢？