您好,欢迎来到中国汽车电子电气架构发展论坛2020!

软件定义汽车危机:为什么说变革时期需要马斯克这样的领导人?

发布日期:2020-09-11

Leo Huang SDV 汽车电子电气架构创新发展论坛 今天 

手机阅读



点击上方蓝色字体,关注我们



引言

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

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

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






01

 软件危机


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

  • 成本日益增长

  • 开发进度难以控制

  • 软件质量差

  • 软件维护困难

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

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

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

  • 为什么修好了一个 bug,又冒出来几个其他 bug?

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

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

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

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

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

  • 为什么......




02

软件与 EE 的冲突


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

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

  • 功能定义及分配

  • 网络拓扑及信号分析

  • 信号及接口定义

  • 电源分配

  • 线束设计

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

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

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



03

功能域相互扯皮


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

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

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

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



04

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


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

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

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

车型平台


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

  • 缩减开发成本

  • 缩减产品开发周期

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




05

传统车厂的历史包袱


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

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

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

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

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

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

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

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

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

  • 芯片平台不同

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

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

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

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

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

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

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

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

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

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



06

总结


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

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

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

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

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

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


来源:汽车电子与软件





相关文章

SDV时代,OEM该做软件开发吗?
汽车OTA哪家强?
谈谈“汽车软件产品SWAP”




SELECTED EVENTS




 

长按二维码识别关注


 

/长按二维码申请加入 EEA 技术交流群/ 


我就知道你“在看”


  • 电话咨询
  • 021-22306692
  • 15021948198
None