软件定义汽车(第九集)危机是如何酿成的.docVIP

软件定义汽车(第九集)危机是如何酿成的 1 软件危机 软件危机是软件工程领域的一个说法，说的就是软件工程中所表现出的各种问题，主要体现为以下几点。 成本日益增长 开发进度难以控制 软件质量差 软件维护困难 看起来比较抽象，我举几个具体的例子，大家自检一下： 为什么别人家的软件一个月可以更新好几次，而自家半年过去了，非常努力的敏捷开发而一个版本也发不出来？ 为什么每个功能域都觉得自己没问题了，集成到一起就问题层出不穷？ 为什么修好了一个 bug，又冒出来几个其他 bug？ 为什么开发告诉我这个功能技术方案太复杂，这期来不及，以后再做，然而以后还是来不及？ 为什么一些功能逻辑只有到了实车上，才发现原先的设计逻辑有问题？ 为什么第一款车已经做过一遍了，这款新车就适配一下，还需要这么长时间？ 为什么规划了个新架构，到最后只能做点小优化？ 为什么开发告诉我，自己要维护十几套代码基线，功能不都差不多吗？ 为什么...... 2 软件与 EE 的冲突 无法掌控电子架构，软件架构就是空中楼阁，软件部门经常会和 EE 打交道，特别是在新的软件化浪潮下，双方经常会起冲突。其实静下心来分析，这种冲突是双方认知不同造成的必然结果。 传统的EE一般来自于电气、电气自动化、汽车等相关专业，主要有以下几个重要职责： 功能定义及分配 网络拓扑及信号分析 信号及接口定义 电源分配 线束设计 在传统的离散架构下，其工作以信号为基础，围绕网络与零部件展开，车上的很多功能往往需要多个 ECU 相互配合，定义功能逻辑、信号交互、管理 ECU 零部件开发是日常的工作重心。 在传统的架构下，其工作模式其实是至下而上的，所有的功能性 ECU 都是产业链上有的，组合起来形成各种产品功能。 而在新架构下，工作模式需要至上而下，底层 ECU 提供的都是原子功能，功能逻辑都是在中央计算单元中实现。所以原本的功能定义和划分职责，现在变成了功能拆解、原子服务定义。 3 功能域相互扯皮 在传统的架构下，如果组建开发团队，很自然的就会按照零部件或者功能域去划分，比如智驾、座舱、网关、BCM、VCU 等，一旦这种组织架构形成，想要推行新的技术架构，就会产生非常大的阻力。 组织架构往往是由分工边界决定的，一旦组织架构确定，就会形成一个利益团体，有句话叫撼动利益，比撼动灵魂还难。 举个例子，在中央计算架构下，中央网关退化为多个区域网关，之前中央网关开发的人去干嘛？把 BCM 和 VCU 的业务功能放到中央计算单元的车控单元之后，这些业务由谁来开发？新的架构要取消这两个 ECU，原来的开发部门会同意？ 从这个维度来看，你就知道为什么在传统车厂内部搞这种底层的数字化架构基本没戏，这不是一个单纯的技术问题。另外，如果出去单独成立新软件公司，如果不能决定 EE 架构的，基本也没戏！ 4 车型项目与数字架构平台化 所有的公司刚开始做的时候，毫无疑问最关注还是产品功能，不管怎样先把产品弄出来再说，所有的资源都是围绕着车型的项目在推动。 等到一个车型项目做完，下一个车型项目又开始了，一旦这个过程启动，任何有点技术风险尝试都会被扼杀在摇篮当中，所以永远只能做渐进式的改变，这就导致，会衍生出很多个软件版本。以后每增加一款车型，就要多维护一条产品线。 在靠硬件差异化拼天下的时代，传统的巨头都是车型平台化设计的高手。一个车型平台，需要投入上百亿的资金进行研发，一家大型的车企，可能同时拥有几十款车型，如果每款车的架构都是不一样的，全部都重新开发，这个成本谁也无法承受。 车型平台 我想在他们内部也不会有人质疑，为什么要花这么大的成本去开发这样一个车型平台，因为经过了时间的检验，采用平台化设计为他们带来了很多好处： 缩减开发成本 缩减产品开发周期 为不同车型的硬件差异化提供了基础 5 传统车厂的历史包袱 在传统的汽车上，一个零部件随着整车出厂之后，软件一般不会再进行升级，但在OTA的大背景下，车的生命周期被延长，软件在一定的周期内会进行不断的迭代，如果没有平台化的软件作为支持，产品功能的迭代会产生巨大的工作量，而且迭代速度会非常缓慢。 按照传统车厂的节奏，会频繁的推出新的车型，如果没有平台化的软件作为支撑，光是车型适配的工作就会产生大量的开发成本，更不要谈后续的OTA升级，以后每增加一款车型，就要多维护一条产品线，到了最后，可能不得不去放弃一些销量较低的车型的软件迭代工作，这对于购买那些车的用户来讲公平吗。 在传统的印象中，软件为什么毛利润那么高？很重要的一个原因是软件的可复制性，在复制部署的过程中，其边际成本趋近于零。而软件可复制部署的前提是软硬件的平台化。要在一辆未经良好设计的汽车上去迭代软件，后期本身就会演变成一个灾难。 国内车联网的先行者第一款车发布的时候整个人员规模也就300人左右，后续随着体系内的车型不断变多，