软件定义汽车9-危机是如何酿成的

2020-09-10  本文已影响0人  leo_huang_

引言

又是一个思绪乱飞的夜晚，花了7个小时码出了下面这些内容，今天不讲技术，主要谈谈之前的一些经验教训供大家参考。

大家经常会听到车厂要招几千上万人的软件团队，先不看具体的内容，听起来好像软件就是一个劳动密集型的产业，只要堆人就行了。
殊不知，这只是在从一个坑跳进另外一个更深的坑，新势力们已经构建起了部分的软件能力，传统的车厂正在努力追赶，这个行业一片欣欣向荣的景象，但先行者的很多的经验教训是值得大家好好反思的。

前段时间，大家都在谈传统车厂的软件危机，这些都是不具备能力所产生的危机，等到大家都有软件团队了，更多的危机还在酝酿当中，汽车技术的复杂性，进一步让这些危机更加明显。


image.png

软件危机

软件危机是软件工程领域的一个说法，说的就是软件工程中所表现出的各种问题，主要体现为以下几点。

看起来比较抽象，我举几个具体的例子，大家自检一下：

软件与 EE 的冲突

无法掌控电子架构，软件架构就是空中楼阁，软件部门经常会和 EE 打交道，特别是在新的软件化浪潮下，双方经常会起冲突。其实静下心来分析，这种冲突是双方认知不同造成的必然结果。

传统的EE一般来自于电气、电气自动化、汽车等相关专业，主要有以下几个重要职责：

在传统的离散架构下，其工作以信号为基础，围绕网络与零部件展开，车上的很多功能往往需要多个 ECU 相互配合，定义功能逻辑、信号交互、管理 ECU 零部件开发是日常的工作重心。

在传统的架构下，其工作模式其实是至下而上的，所有的功能性 ECU 都是产业链上有的，组合起来形成各种产品功能。

而在新架构下，工作模式需要至上而下，底层 ECU 提供的都是原子功能，功能逻辑都是在中央计算单元中实现。所以原本的功能定义和划分职责，现在变成了功能拆解、原子服务定义。

功能域相互扯皮

在传统的架构下，如果组建开发团队，很自然的就会按照零部件或者功能域去划分，比如智驾、座舱、网关、BCM、VCU 等，一旦这种组织架构形成，想要推行新的技术架构，就会产生非常大的阻力。

组织架构往往是由分工边界决定的，一旦组织架构确定，就会形成一个利益团体，有句话叫撼动利益，比撼动灵魂还难。

举个例子，在中央计算架构下，中央网关退化为多个区域网关，之前中央网关开发的人去干嘛？ 把 BCM 和 VCU 的业务功能放到中央计算单元的车控单元之后，这些业务由谁来开发？新的架构要取消这两个 ECU，原来的开发部门会同意？

从这个维度来看，你就知道为什么在传统车厂内部搞这种底层的数字化架构基本没戏，这不是一个单纯的技术问题。另外，如果出去单独成立新软件公司，如果不能决定 EE 架构的，基本也没戏！

车型项目与数字架构平台化

所有的公司刚开始做的时候，毫无疑问最关注还是产品功能，不管怎样先把产品弄出来再说，所有的资源都是围绕着车型的项目在推动。

等到一个车型项目做完，下一个车型项目又开始了，一旦这个过程启动，任何有点技术风险尝试都会被扼杀在摇篮当中，所以永远只能做渐进式的改变，这就导致，会衍生出很多个软件版本。以后每增加一款车型，就要多维护一条产品线。

在靠硬件差异化拼天下的时代，传统的巨头都是车型平台化设计的高手。一个车型平台，需要投入上百亿的资金进行研发，一家大型的车企，可能同时拥有几十款车型，如果每款车的架构都是不一样的，全部都重新开发，这个成本谁也无法承受。

车型平台.JPEG

我想在他们内部也不会有人质疑，为什么要花这么大的成本去开发这样一个车型平台，因为经过了时间的检验，采用平台化设计为他们带来了很多好处：

传统车厂的历史包袱

在传统的汽车上，一个零部件随着整车出厂之后，软件一般不会再进行升级，但在OTA的大背景下，车的生命周期被延长，软件在一定的周期内会进行不断的迭代，如果没有平台化的软件作为支持，产品功能的迭代会产生巨大的工作量，而且迭代速度会非常缓慢。

按照传统车厂的节奏，会频繁的推出新的车型，如果没有平台化的软件作为支撑，光是车型适配的工作就会产生大量的开发成本，更不要谈后续的OTA升级，以后每增加一款车型，就要多维护一条产品线，到了最后，可能不得不去放弃一些销量较低的车型的软件迭代工作，这对于购买那些车的用户来讲公平吗。

在传统的印象中，软件为什么毛利润那么高？很重要的一个原因是软件的可复制性，在复制部署的过程中，其边际成本趋近于零。而软件可复制部署的前提是软硬件的平台化。要在一辆未经良好设计的汽车上去迭代软件，后期本身就会演变成一个灾难。

国内车联网的先行者第一款车发布的时候整个人员规模也就300人左右，后续随着体系内的车型不断变多，导致的适配工作呈现倍数放大，人员规模很快膨胀到近千人，主要的资源力量都被吸引到了车型适配当中去，无形之中也影响到了主线产品的开发节奏，即使是把这部分工作交给外包去做，依然也要付出巨大的人工成本。

为什么会产生如此大的适配工作量呢？可以先给大家介绍一下，软件适配车型具体的工作范围。

车载软件系统，开发出来之后，只要芯片平台不变，操作系统不变，按道理来讲是不需要什么适配工作的。但是但由于传统车厂的一些历史遗留问题，以及产品设计理念的问题，会产生以下三类问题。

以上的这些因素都会导致软件的变更，而软件的变更也分为几个层次，软件工程中一般会使用git等工具来管理代码，在软件开发过程中，几十上百个软件工程师会共同完成同一个项目，这里面很重要的概念就是“主线”与“分支”，如果多个车型项目的代码能够复用同一“主线”，意味者他们的代码是同一套，工作量会小很多，但是如果某个车型的软件变更，导致他们无法再用同一套，在软件上就会产生一个新的分支，就像大家平时多个人要共同编辑某个文档，一旦大家的修改产生了分叉，就必须同时维护多个版本。

从软件工程的角度来开，软件开发的一般分为，需求分析、领域建模、架构/概要/详细设计、开发/单元测试、综合测试、编译集成、发布等几个阶段。每增加一个分支，就会导致从开发开始所有流程工作量的增加。

从软件的角度来看，采用一些技术上的设计，可以复用已有的模块分为以下几个层次：

有人也许会问，为啥要搞这么复杂，每个车型都采用不同代码，不是更好管理吗？ 传统车厂包给Tier1做的时候，也的确是这样，因为那个时代，软件和硬件一样，都是一锤子的买卖，不需要后续还进行什么升级。今天我们谈论软件定义汽车的前提就是，要通过OTA不断的为车升级新的功能。 如果都采用不同的代码版本，意味着软件开发团队的规模是和车型的数量成正比的，越往后面迭代，已有的车型都会变成历史的包袱。

很多时候，大家在开始做项目的时候，最关注的还是产品功能的实现度，很少关心软件的架构设计和拓展性，积累到一定的阶段，又不敢轻易的进行重构，而后产生恶性循环，导致开发资源的大量浪费，功能大家都能做，但工程能力的高低往往体现在这些看不见的地方。

构建一套基础的软硬件平台，通过良好的架构设计，在标准的软硬件基础设施上，开发出完备的工具链，以支持车型功能的快速开发与快速迭代，是软件定义汽车的基础。

总结

写了比较多的内容，思路也比较发散，总结下来有以下几点建议：

上一篇下一篇

猜你喜欢

热点阅读