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

我们经常听到车厂在招募几千人甚至几万人的软件团队，不看具体内容，听起来软件是个只需要很多人的劳动密集型行业。然而，这只是从一个坑跳到另一个更深的坑。新势力已经积累了一些软件能力，传统车厂也在努力追赶。行业欣欣向荣，但先行者的许多经验教训值得反思。前段时间大家都在说传统车厂的软件危机，这些都是能力不足导致的危机，当大家都有软件团队的时候，更多的危机还在酝酿。汽车技术的复杂性进一步让这些危机更加明显。

软件危机

软件危机是软件工程领域的一个术语，指的是软件工程中出现的各种问题，主要体现在以下几点。

好像有些抽象，我举几个具体的例子，大家可以自己检查一下：

2 软件与 EE 之间的冲突

没有电子架构的把控，软件架构只是空中楼阁。软件部门经常和EE打交道，特别是在新一轮软件化浪潮中，双方经常发生冲突。其实如果静下心来分析，这种冲突是双方认知不同必然的结果。

传统EE一般来自电气、电气自动化、汽车等相关专业，承担以下重要职责：

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

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

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

3 功能域相互争论

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

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

比如在中央计算架构下，中央网关退化为多个区域网关，之前开发中央网关的人会怎么办？BCM、VCU的业务功能放到中央计算单元整车控制单元之后，谁来开发这些业务？新的架构要取消这两个ECU，原来的开发部门会同意吗？

从这个角度你就可以理解为什么传统车厂内部基本上不可能开发这种底层数字架构，这不仅仅是一个简单的技术问题。另外，如果你自己出去成立一家新的软件公司，如果不能决定EE架构，那基本上是不可能的！

4 样板工程及数字建筑平台化

所有企业在刚起步的时候，毫无疑问最重视的就是产品特色，不管怎样都要先把产品做出来，所有的资源都围绕车型项目来带动。

当一个型号的项目完成后，下一个型号就开始了。一旦这个过程开始，任何稍有技术风险的尝试都会被扼杀在摇篮里，因此只能进行增量更改，这导致许多软件版本的产生。每增加一个新型号，就必须维护一条额外的产品线。

在硬件差异化是致胜法宝的时代，传统巨头都是车机平台设计的高手，一个车机平台需要几百亿的研发投入，一个大型车厂可能同时有几十款车型，如果每款车的架构都不一样，全部都需要重新开发，成本是难以承受的。

车辆平台

我想他们公司里没有人会质疑为什么要花那么多钱开发这样的车辆平台，因为经过时间的考验，这个平台设计给他们带来了很多好处：

5. 传统汽车制造商的历史包袱

传统汽车中，车辆出厂后，一般不会对部件的软件进行升级，但在OTA背景下，车辆生命周期延长，软件会在一定周期内不断迭代，如果没有平台软件支撑，产品功能的迭代会产生巨大的工作量，迭代速度也会非常缓慢。

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

传统印象中，软件的毛利率为什么那么高？一个很重要的原因就是软件的可复制性。在复制部署的过程中，它的边际成本趋近于零。软件可复制部署的前提是软件和硬件的平台化。在一辆设计并不完善的汽车上迭代软件，后期会变成一场灾难。

这家国内车联网先行者首款车型发布时，总员工规模只有300人左右。后来随着体系内车型不断增多，适配工作成倍增加，员工规模迅速扩大到近千人。主要资源都吸引到车型适配上，无形中影响了主力产品的开发节奏，即便将这部分工作外包出去，也需要耗费巨大的人力。

为什么适配的工作量会这么巨大呢?我先给大家介绍一下软件适配模型的具体工作范围。

车载软件系统开发完成后，只要芯片平台和操作系统不变，按理说不需要做任何适配工作，但由于传统车厂的一些历史遗留问题，以及产品设计理念的问题，会出现以下三类问题。

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

从软件工程的角度看，软件开发一般分为需求分析、领域建模、架构/概要/详细设计、开发/单元测试、全面测试、编译集成、发布几个阶段产生软件危机的原因有如下几点 除了，每增加一个分支，都会增加从开发开始的所有流程的工作量。

从软件角度来看，可以采用一些技术设计，在以下层面上重用现有的模块：

有人会问，干嘛这么复杂？每个车型都用不同的代码不是更容易管理吗？传统车厂把活儿外包给 Tier 1 的时候也是这样，因为那时候软件跟硬件一样，都是一次性的，不需要后续任何升级。我们今天讨论软件定义汽车的前提，就是通过 OTA 不断为汽车升级新功能。如果使用不同的代码版本，就意味着软件开发团队的规模和车型数量成正比，迭代越多，已有的车型就会成为历史包袱。

很多时候产生软件危机的原因有如下几点 除了，人们开始做一个项目的时候，最关注的是产品功能的实现程度，很少关心软件的架构设计和可扩展性。当积累到一定阶段，就不敢轻易进行重构，这就形成了一个恶性循环，导致了开发资源的巨大浪费。功能谁都会做，但工程能力的高低往往就体现在这些看不见的地方。

构建基础软硬件平台，通过良好的架构设计，在标准的软硬件基础架构上开发完整的工具链，支撑车辆功能的快速开发和迭代，是软件定义汽车的基础。

6 结论

写了不少内容，思路也比较发散，总结一下，我有以下几点建议：