前言：

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

上月汇总|2020年9月各大机构发布汽车精选研报合集（共92份-点击下载）

1

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

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

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

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

所以，软件定义汽车对于OEM而言，其目的就是：

提升销量：搞出一些牛X的功能或极致的体验，让车能多卖一些。

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

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

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

OEM的自研范围：要自己搞软件，应该搞哪些呢？

软件如何持续迭代：搞了这么多软件，怎么保证它能快速、持续的迭代呢？

2

研发路线图

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

《人月神话》中提到了一条定律叫康威定律（Conways law）：

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organizations 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 李成仙 | 软件架构师

—END—

技术交流群：YasmineMiao（微信）

投稿合作：18918250345（微信）