登陆

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

来源：公众号“汽车电子与软件”

2020-09-23

2434

作者 | Peter 李成仙

来源 | 汽车电子与软件

前言：

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

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

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

软件占整车的价值比例将会越来越大，未来可超过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服务拆分完毕之后，新的问题就出现了：