简单聊聊汽车 OTA 给 OEM 和 Tire1 带来的变化

随着通信带宽和速度的提升，车联网时代紧随而来。以前只能在电子产品上看到的 OTA 功能，也逐渐出现在汽车上。各大 OEM 厂商为了表现自家产品的科技感，在越来越多的车型中加入了 OTA 功能。

谈到 OTA 功能，TBOX 是不可绕过的一个环节。TBOX 全称 Telematics BOX，是车联网设备的终端，也是实现 OTA 必须具备的 ECU。当然，TBOX 并非只实现 OTA 功能，比如说远程监控、远程诊断、防盗等功能。

我曾参与过某 OEM 的 TBOX 设备开发，经历了从项目立项到产品 SOP 的每个环节。今天，不聊 TBOX 和 OTA 的技术细节，而是聊聊 OTA 对于 OEM 和供应商的影响。

对于供应商来说，OTA 功能是产品的卖点，能够提升自家产品的价格。同时，OTA 也能让供应商长久赚钱，这个后面细说。

对于 OEM 来说，OTA 是体现自家产品科技感的重要卖点，能够吸引用户，然而这个功能也需要 OEM 需要长久花钱维护。

OTA 功能实现难么，说实话难度并不大。汽车供应商也是采购模组供应商的芯片模组，而模组供应商已经在底层实现了 OTA 功能，并开放了底层接口。汽车供应商只需使用底层接口进行上层业务开发即可。

接下来说说 OTA 功能为何会让 OEM 花钱，供应商赚钱呢？

首先，我们要明白 OTA 功能是为了让用户购买了汽车后，在使用的过程中对于车辆的软件进行远程升级。

在没有 OTA 功能之前，OEM 开发新车型的周期比较长，一般为 2 到 3 年。由于汽车上有很多 ECU，每个 ECU 都必须经历严格的测试，保证其功能稳定、没有缺陷，才能最终 SOP。

因此，这在某种程度上拉长了开发周期。另外，传统的汽车软件开发遵循“V”开发模型，这就要求在开发之前要冻结所有的软件需求。一旦进入开发阶段，除非非改不可，否则软件需求不可变更。

在具备 OTA 功能之后，理论上来说 OEM 开发新车型的周期会大大缩短，因为 OEM 可以先提出核心或优先级最高的需求。至于优先级较低的需求，可以在后续通过 OTA 的方式快速迭代。

然而，想法是美好的，但 OEM 的做法却大相径庭。根据我的经验，OEM 不会选择按照需求优先级进行快速迭代。我认为有以下两点原因：

第一，OEM 的传统思维还未扭转。传统汽车软件开发时代，汽车软件遵循的 V 开发模型要求开发之前冻结所有软件需求。哪怕现在车辆有了 OTA 功能，具备了快速迭代的能力，OEM 仍旧按照传统思维来开发新车，即在开发之前把能想到的需求全部提出来，而不分需求的优先级有步骤的实现。这种做法让 OTA 功能显得有些鸡肋。

第二，OEM 需要考虑开发成本。汽车一旦进行 OTA 意味着要么软件有 bug，要么增加了新功能。对于软件 bug，由于是零部件供应商自己的问题，因此修复软件 bug 是供应商的责任。然而，对于新功能，可以理解为 OEM 提出的新需求让供应商完成，这就涉及到新功能开发。供应商会与 OEM 谈商务，针对新功能开发提出合理的价钱。也即是说，车辆 OTA 升级新功能时，OEM 是要付费给供应商的。如果新功能涉多个 ECU，且难度比较大，那么 OEM 花费的钱还是不少的。当然也有例外，比如，小鹏和特斯拉 OTA 升级的付费功能就是将开发成本分摊到用户身上。

上面这两点原因导致 OEM 在开发新车型时会把能想到的需求全部一股脑的提出来，使得供应商开发周期加长、软件复杂度提升。因此，软件 bug 不可避免，但修复 bug 却是免费的，OEM 从中可以节省大量成本。

就我个人开发 TBOX 的经验来说，某 OEM 给我们的 TBOX 需求文档接近两千页。在开发软件的过程中，看到一些奇葩需求，我会与同事开玩笑说“用户把车开报废可能都无法发现这个功能”。

但是，我认为这只是 OTA 发展和普及过程中的小问题，供应商和 OEM 的暂时还没找到合适的玩法。随着技术程度和经验的丰富，两者一定能够找到最好的合作方式使供应商、OEM 和用户都从中受益。

文章首发于上汽零束开发者论坛。

作者：程序猿司晨

文章来源：上汽零束 SOA 开发者论坛

原文链接：https://bbs.z-onesoft.com/omp/community/front/api/page/mainTz?articleId=7499