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

引言：

又是一个思绪乱飞的夜晚，花了7个小时码出了下面这些内容，今天不讲技术，主要谈谈之前的一些经验教训供大家参考。 大家经常会听到车厂要招几千上万人的软件团队，先不看具体的内容，听起来好像软件就是一个劳动密集型的产业，只要堆人就行了。殊不知，这只是在从一个坑跳进另外一个更深的坑，新势力们已经构建起了部分的软件能力，传统的车厂正在努力追赶，这个行业一片欣欣向荣的景象，但先行者的很多的经验教训是值得大家好好反思的。前段时间，大家都在谈传统车厂的软件危机，这些都是不具备能力所产生的危机，等到大家都有软件团队了，更多的危机还在酝酿当中，汽车技术的复杂性，进一步让这些危机更加明显。

1

软件危机

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

成本日益增长

开发进度难以控制

软件质量差

软件维护困难

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

为什么别人家的软件一个月可以更新好几次，而自家半年过去了，非常努力的敏捷开发而一个版本也发不出来？

为什么每个功能域都觉得自己没问题了，集成到一起就问题层出不穷？

为什么修好了一个 bug，又冒出来几个其他 bug？

为什么开发告诉我这个功能技术方案太复杂，这期来不及，以后再做，然而以后还是来不及？

为什么一些功能逻辑只有到了实车上，才发现原先的设计逻辑有问题？

为什么第一款车已经做过一遍了，这款新车就适配一下，还需要这么长时间？

为什么规划了个新架构，到最后只能做点小优化？

为什么开发告诉我，自己要维护十几套代码基线，功能不都差不多吗？

为什么......

2

软件与 EE 的冲突

无法掌控电子架构，软件架构就是空中楼阁，软件部门经常会和 EE 打交道，特别是在新的软件化浪潮下，双方经常会起冲突。其实静下心来分析，这种冲突是双方认知不同造成的必然结果。 传统的EE一般来自于电气、电气自动化、汽车等相关专业，主要有以下几个重要职责：

功能定义及分配

网络拓扑及信号分析

信号及接口定义

电源分配

线束设计

在传统的离散架构下，其工作以信号为基础，围绕网络与零部件展开，车上的很多功能往往需要多个 ECU 相互配合，定义功能逻辑、信号交互、管理 ECU 零部件开发是日常的工作重心。 在传统的架构下，其工作模式其实是至下而上的，所有的功能性 ECU 都是产业链上有的，组合起来形成各种产品功能。 而在新架构下，工作模式需要至上而下，底层 ECU 提供的都是原子功能，功能逻辑都是在中央计算单元中实现。所以原本的功能定义和划分职责，现在变成了功能拆解、原子服务定义。

3

功能域相互扯皮

在传统的架构下，如果组建开发团队，很自然的就会按照零部件或者功能域去划分，比如智驾、座舱、网关、BCM、VCU 等，一旦这种组织架构形成，想要推行新的技术架构，就会产生非常大的阻力。 组织架构往往是由分工边界决定的，一旦组织架构确定，就会形成一个利益团体，有句话叫撼动利益，比撼动灵魂还难。 举个例子，在中央计算架构下，中央网关退化为多个区域网关，之前中央网关开发的人去干嘛？把 BCM 和 VCU 的业务功能放到中央计算单元的车控单元之后，这些业务由谁来开发？新的架构要取消这两个 ECU，原来的开发部门会同意？ 从这个维度来看，你就知道为什么在传统车厂内部搞这种底层的数字化架构基本没戏，这不是一个单纯的技术问题。另外，如果出去单独成立新软件公司，如果不能决定 EE 架构的，基本也没戏！

4

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

所有的公司刚开始做的时候，毫无疑问最关注还是产品功能，不管怎样先把产品弄出来再说，所有的资源都是围绕着车型的项目在推动。 等到一个车型项目做完，下一个车型项目又开始了，一旦这个过程启动，任何有点技术风险尝试都会被扼杀在摇篮当中，所以永远只能做渐进式的改变，这就导致，会衍生出很多个软件版本。以后每增加一款车型，就要多维护一条产品线。 在靠硬件差异化拼天下的时代，传统的巨头都是车型平台化设计的高手。一个车型平台，需要投入上百亿的资金进行研发，一家大型的车企，可能同时拥有几十款车型，如果每款车的架构都是不一样的，全部都重新开发，这个成本谁也无法承受。

车型平台

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

缩减开发成本

缩减产品开发周期

为不同车型的硬件差异化提供了基础

5

传统车厂的历史包袱

在传统的汽车上，一个零部件随着整车出厂之后，软件一般不会再进行升级，但在OTA的大背景下，车的生命周期被延长，软件在一定的周期内会进行不断的迭代，如果没有平台化的软件作为支持，产品功能的迭代会产生巨大的工作量，而且迭代速度会非常缓慢。 按照传统车厂的节奏，会频繁的推出新的车型，如果没有平台化的软件作为支撑，光是车型适配的工作就会产生大量的开发成本，更不要谈后续的OTA升级，以后每增加一款车型，就要多维护一条产品线，到了最后，可能不得不去放弃一些销量较低的车型的软件迭代工作，这对于购买那些车的用户来讲公平吗。 在传统的印象中，软件为什么毛利润那么高？很重要的一个原因是软件的可复制性，在复制部署的过程中，其边际成本趋近于零。而软件可复制部署的前提是软硬件的平台化。要在一辆未经良好设计的汽车上去迭代软件，后期本身就会演变成一个灾难。 国内车联网的先行者第一款车发布的时候整个人员规模也就300人左右，后续随着体系内的车型不断变多，导致的适配工作呈现倍数放大，人员规模很快膨胀到近千人，主要的资源力量都被吸引到了车型适配当中去，无形之中也影响到了主线产品的开发节奏，即使是把这部分工作交给外包去做，依然也要付出巨大的人工成本。 为什么会产生如此大的适配工作量呢？可以先给大家介绍一下，软件适配车型具体的工作范围。 车载软件系统，开发出来之后，只要芯片平台不变，操作系统不变，按道理来讲是不需要什么适配工作的。但是但由于传统车厂的一些历史遗留问题，以及产品设计理念的问题，会产生以下三类问题。

车型平台、车型信号不同，导致信号的适配
新的车型，如果是基于同一个车型平台开发出来，其一般只是信号的值，或者信号的个数发生了变化，但是如果两款车基于完全不同的车型开发出来，基本上信号共用的部分就很少，同样是控制某个功能，信号的名称可能完全不一样，并且一个车型上发一个信号能完成的功能，到了另外一个车型上，可能需要多个信号组合才能完成。这会导致，像网关、TBOX、域控MCU、域控MPU的车辆信号处理的中间件、HMI控制逻辑等模块需要进行软件变更。此类功能，是车载软件开发中联调工作最大的部分，并且还必须是在早期就具备的功能，比如PPV阶段，就要求此类功能ready，而其他大部分功能都可以放到SOP阶段，和其他零部件交互的功能，都是联调中最麻烦的，特别是在早期阶段，工程师需要跑各种现场分析解决问题。

屏幕适配
咱们国内的整车的产品人员对智能化的理解是不是太肤浅了，喜欢定义各种规格的屏幕尺寸，多搞几块屏幕，没事儿还横屏改竖屏，竖屏改横屏，似乎谁的屏幕多、屏幕大就更智能似的。殊不知，多一块屏幕或者是改变了屏幕的横竖关系，就要重新定义交互方式，而改变屏幕分辨率，也会导致UI布局上的调整， 这些改变会导致软件上巨大的工作量。

车型特殊硬件，增加新的软件模块
传统车厂的车型产品中，喜欢弄一些差异化的硬件，而这些功能往往需要增加新的软件模块才能运行，此类功能倒是比较好处理，因为新增的模块总比改已有的模块要方便，新增只影响一个车型，而改已有的模块会影响其他所有车型。

芯片平台不同

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

从软件工程的角度来讲，软件开发的一般分为，需求分析、领域建模、架构/概要/详细设计、开发/单元测试、综合测试、编译集成、发布等几个阶段。每增加一个分支，就会导致从开发开始所有流程工作量的增加。 从软件的角度来看，采用一些技术上的设计，可以复用已有的模块分为以下几个层次：

共用同一分支，一次编译，生成一个软件包，能够在所有车型上运行（就像app能够在所有Android手机上运行）。

共用同一分支，多次编译，生成多个软件包，能够在不用车型上运行。

部分模块共用同一分支，多次编译，生成多个软件包，能够在不用车型上运行。

采用不同分支，多次编译，生成多个软件包，能够在不用车型上运行。

有人也许会问，为啥要搞这么复杂，每个车型都采用不同代码，不是更好管理吗？传统车厂包给Tier1做的时候，也的确是这样，因为那个时代，软件和硬件一样，都是一锤子的买卖，不需要后续还进行什么升级。今天我们谈论软件定义汽车的前提就是，要通过OTA不断的为车升级新的功能。如果都采用不同的代码版本，意味着软件开发团队的规模是和车型的数量成正比的，越往后面迭代，已有的车型都会变成历史的包袱。 很多时候，大家在开始做项目的时候，最关注的还是产品功能的实现度，很少关心软件的架构设计和拓展性，积累到一定的阶段，又不敢轻易的进行重构，而后产生恶性循环，导致开发资源的大量浪费，功能大家都能做，但工程能力的高低往往体现在这些看不见的地方。 构建一套基础的软硬件平台，通过良好的架构设计，在标准的软硬件基础设施上，开发出完备的工具链，以支持车型功能的快速开发与快速迭代，是软件定义汽车的基础。

6

总结

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

在构建新的数字化架构的过程中，如果牵头人不是像马斯克这种有技术决断力的领导，最好就构建一个强有力的架构团队，从技术层面总领全局，否则靠功能域自己相互协调，只能做点优化，改变不了基础架构。

构建的架构团队必须包含定义计算通信架构的职责，靠 EE 和软件架构各自为战，做出来的也是个渐进产品。

各功能域的职责在新的技术架构下是会发生变化的，不要试图在原有的组织架构下搞出新的技术架构。

产品线开发和平台开发要分开，否则就会面临边开飞机边换引擎的惨痛局面，开发资源永远被现有项目所围困。

新平台的开发是一个 EE+硬件+软件的综合体，如果总想拿正式车型项目去推动，会让项目面临很多不可控风险。新平台的正向研发过程中面临很多技术决断，建议成立一只独立团队开展前期研究工作。在一定阶段导入正式量产项目。本质是把 R&D 中的 Research 与 Development 分开，并且将 R 前置。

原文标题：软件定义汽车 (第九集) : 危机是如何酿成的

文章出处：【微信公众号：佐思汽车研究】欢迎添加关注！文章转载请注明出处。

责任编辑：haq