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

软件定义汽车之OEM研发路线图

发布日期:2020-09-23

Peter 李成仙 汽车电子电气架构创新发展论坛 今天 

手机阅读

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

前言:


软件定义汽车相关的文章还是较多的,写整体趋势的,写局部方法论的,写工具与标准的。但“软件定义汽车”趋势的主角OEM更希望看到的是一张路线图。这样的话,OEM可根据当前能力去定义下一步该如何实施,再下一步往哪个方向走,以及*终目标是什么?


1
件定义汽车的目标及基本问题


首先,重温一下“软件定义汽车”的重点:

  • 软件占整车的价值比例将会越来越大,未来可超过60%,下图就是众OEM的梦想:

  • 软件可不断迭代,给予整车“常用常新”的用户体验,并使整车增值。


所以,“软件定义汽车”对于OEM而言,其目的就是:

  • 提升销量:搞出一些牛X的功能或**的体验,让车能多卖一些。

  • 用户粘性:持续的与用户发生关系,不断的给用户新的增值服务,让用户心甘情愿的掏钱

  • 提升市值:多搞研发,让企业估值从传统制造企业向高科技企业的方向转变


那么,在想通了这些目的之后,“软件定义汽车”的基本问题就是:

  • OEM的自研范围:要自己搞软件,应该搞哪些呢?

  • 软件如何持续迭代:搞了这么多软件,怎么保证它能快速、持续的迭代呢?


2

研发路线图


2.1 软件定义汽车需要企业级的变革与转型


《人月神话》中提到了一条定律叫“康威定律”(Conway's law):
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
任何组织设计的系统的技术架构都与其组织的沟通架构一样。
意译过来就是“组织架构决定技术架构”。
同样的,在详细展开“研发路线图”之前,也需要指出的是“软件定义汽车”并非仅仅是研发部门的工作,其余部门也需要同时进行数字化转型,引入大数据、人工智能、云计算等技术,以适应新的技术架构。否则“技术架构”将被“组织架构”束缚,无法顺利开展。用笔者接触过的几个领域来说,举几个简单例子:

  • 人事:面对“软件定义汽车”这种新兴趋势,很多方面尚待探索,如何激发员工的积极主动性呢?

  • 品牌:手机行业的调研显示,品牌力的强弱与用户的后付费意愿度成正比,那么如何打造OEM的品牌呢?

  • 用户运营:OEM在收集了那么多数据之后,如何利用大数据来做用户运营呢?

  • 产线:在软件可以做到频繁更新迭代之后,产线需要如何配合,才能不被频繁的打断呢?

  • 工艺:在硬件占比注定持续性下降的趋势下,如何改进工艺,才能以更低的成本达到同样的性能水平呢?

软件定义汽车趋势下的OEM能力总览

上图中将OEM研发能力按3+2来分,纵向的“智能座舱”+“智能驾驶”+“车辆控制”,横向的“SOA架构”与“EEA架构”。若对SOA架构的必要性不了解的,可参考我之前的文章《技术闲谈之汽车SOA》。
大的能力分类仅分为三类,可根据此来重新设计组织架构:

  • 产品定义能力:智能化的产品需要强大的“场景定义能力”,产品经理应该三域通盘考虑。

  • 软件能力:车端的代码主要分为C/C++,及JAVA,代码能力与软件架构能力各域本是相通的。

  • 架构能力:各域的HPC选型、外设选型在技能上趋同,亦可合并在一起。而SOA、EEA架构更多的考虑的是功能的分配(灰盒与黑盒)、电力/线束的分配等功能,这两者协同合作更佳。


2.2 分阶段的研发路线图


上图中的“能力”区分较多,那么如何分步建立各领域的能力呢?下面是一个优先级及顺序建议。

软件定义汽车之研发路线图

  • 阶段0:EEA架构能力是OEM的基础能力,此处就不做强调了,除非没有量产经验,否则这是必需的。

  • 阶段1:OEM首先应该做的,就是挑某个领域开始自研,这样可以拉通“需求与设计”、“代码编写”、“软件架构”这三方面的能力。

  • 阶段2:在自研1~2年后,或者开始第二个量产项目之后,会发现软件用于适配各种硬件的工作量越来越多,所以,应该在“自研”之后,建立系统架构能力,尽量做到“硬件平台化”,以及“硬件可升级”的目的。

  • 阶段3:把“SOA架构能力”放在*后一阶段实属无奈,因为它需要基于Ethernet来建立,且各域*好都已有自研部分,否则推动供应商实施会较难。它可实现的功能太多,比如可使能整车软件功能的“按需购买”、3月一迭代变成1月一迭代,大幅提高软件复用度等等

  • 职能部门的数字化:再次强调一遍,这件事情需要一直进行,以给研发更好的支持,不拖后腿。

当然,如果OEM的决心足够大看的足够清楚,可以几个阶段并行开始,否则就一个阶段一个阶段来。

2.3 阶段一:软件自研能力评估及范围推荐


针对“软件自研能力”建设,详细展开一下,各域的区别还是不小。

(1) 智能座舱域
下图以智能座舱域中*复杂的Android架构为例,描述了自研能力的分级。一般而言,自研的先后顺序如下:

  • Level 0 ~1 应用层或部分应用:从强用户体验的应用开始逐步深入,直至掌握整个应用层的开发能力。

  • Level 1~2 应用+框架层:在此层适配车型、供应商的差异,相对在应用层适配,代价会小很多。且SOP后,大部分迭代都在此层及以上。

  • Level 2+:不推荐OEM继续深入,除非OEM有自研操作系统或硬件的战略规划。因为HAL层与硬件外设强相关,而操作系统需要投入天量的人力进行开发及维护。



(2) 智能驾驶域
下图参考了《智能驾驶功能软件平台设计规范》,与智能座舱不同,智能驾驶由于更加侧重算法,其独有“功能软件”层。一般而言,推荐的自研深度如下:


  • Level 0 ~1 应用层或部分应用:从OEM想做差异化的场景入手,设定功能应用的场景、判断条件、默认配置、策略及人机交互需求。

  • Level 1~2 控制算法:根据前续模块的输入来完成自车行驶轨迹的决策和规划,并控制车辆。这部分能力大部分新能源车厂都已具备,可以自研。

  • Level 2~3 视觉算法:智能驾驶的核心,由于深度学习算法的开放性,此领域的学术资料较易获得,只是若要量产,还需要大量的训练数据以及模型优化,推荐有条件的车厂自研。

  • Level 3+:不推荐自研,理由与智能座舱的一致。


(3)车辆控制域
车辆控制域都为MCU,当然有一些车厂也开始使用SOC来做车辆域控制器。由于其架构较简单,推荐OEM可自研应用及算法。


2.4 阶段二:系统架构能力建设


系统架构示例

系统架构的能力的核心点在于:如何前瞻性的考虑到未来硬件的升级,而预留的硬件接口及配件?否则,软件功能迭代2~3年后,存储空间满了,CPU不够用了,内存也紧张了。又或者,几年后想增加一个功能,却未预置外设,无法实现,只能做改款。
这一点要做好,也不仅是系统架构的工作,而是OEM需要对自己的产品战略方向非常清晰才行,基本上要提前5年设想好之后的功能及场景。

2.5 阶段三:SOA架构能力建设及问题


(1)SOA架构设计原则
在Ethernet作为主干网进入整车后,SOA就成必然选项。其将给整车的软件开发及迭代带来质的飞跃。

SOA架构下各服务的联系将是动态而普遍的

而SOA的核心问题在于:

(1) 在整车各服务的拆分时,如何做到高内聚、低耦合?

这个答案其实非常简单,只要遵守分布式系统软件架构设计的设计原则即可,网络上有很多资料。以下是一些个人见解,并以“人脸识别”为例,做了详细的阐述:

  • 扩展性:目前这套人脸识别代码只能支持本地存储99张人脸,是否有存储更多人脸的需求?如果有的话,可能就要采用云端与本地同步存储的方案。对外提供的接口也会不同,如增加“同步人脸中”的对外状态。

  • 可靠性:人脸识别的准确率为99.9%,误识别率为0.1%。如果用在车内做个性化坐椅调节没问题,但用于“支付”,这个可靠性就不够,需要更换方案。

  • 性能:人脸识别所需时间需为0.5秒。那么在这个场景中,人脸识别服务与应用可以放在不同的域控制器中,用SOME/IP进行通信。但如果所需时间为0.1秒,人脸识别服务与应用,可能就要放在同一个程序中了。

  • 异常/边界情况:人脸识别失效了怎么办?所以,人脸识别相关的应用必须定义额外的备用选项,使用其他的接口,如手动调节坐椅,输入密码支付等等。

  • 可行性:来了个新需求,要求老板上车时播放定制化的欢迎语,明天必须完成。这时,就不能增加“定制化欢迎语”的功能,而只能在识别到老板后,写死欢迎语了。


(2) SOA架构设计带来的问题
在SOA服务拆分完毕之后,新的问题就出现了:

  • 所有服务都在Ethernet上共享了,那么如何管理权限呢?要不然以后一个第三方应用来直接控制我的方向盘咋办?

  • SOA可以让功能迭代时,各方的工作量减少,加快迭代的速度。但难道每次都走劳民伤财的FOTA吗?

  • 上线了一个付费购买的功能,但用户买了后,如何把功能打开呢?有没有统一的框架呢?

这些问题在Adaptive AUTOSAR中都得到了解决:

  • Identity Access Management:身份认证与权限管理,专治流氓程序

  • Update & Configuration Management: 支持应用升级,月月迭代不是梦;支持远程配置,让买买买更顺滑!

所以,AP的价值还是很高的,强烈建议购买。(抱歉,跟之前文章里的结论不一样,因为他们之前没给我塞钱 :),不不不,其实是因为当时还没看AP的SPEC )


3

总结


再次申明一下:上述的路线图以及自研范围推荐,皆仅供普通OEM参考,土豪请随意!
到此,已经回答了前面的两个问题:

  • OEM的自研范围:要自己搞软件,应该搞哪些呢?

    回答:智能座舱、智能驾驶、车辆控制各有不同的策略

  • 软件如何持续迭代:搞了这么多软件,怎么保证它能快速、持续的迭代呢

    回答:系统架构上做到硬件可升级,整车软件架构支持SOA

愿本文点起的一盏小灯能给在“软件定义汽车”的海洋中找不到方向的OEM一点点方向感。

阅读原文| 关注作者知乎:Peter 李成仙 | 软件架构师

来源:汽车电子与软件


相关文章

SDV变革下,OEM的内功修炼
汽车OTA哪家强?
下载|德勤:软件正在改变汽车世界-纯软件公司并入汽车市场的四个战略选择





SELECTED EVENTS




 

长按二维码识别关注


 

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


我就知道你“在看”


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