本文探讨了软件定义汽车趋势下OEM的研发路线图，包括企业级变革、分阶段研发策略和关键能力建设。建议OEM从软件自研能力评估开始，逐步建立系统架构和SOA架构能力，同时关注品牌建设、用户运营和产线配合等挑战。通过分阶段研发，实现软件的持续迭代和价值提升。
前言：
软件定义汽车相关的文章还是较多的，写整体趋势的，写局部方法论的，写工具与标准的。但“软件定义汽车”趋势的主角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能力总览
产品定义能力：智能化的产品需要强大的“场景定义能力”，产品经理应该三域通盘考虑。
软件能力：车端的代码主要分为C/C++，及JAVA，代码能力与软件架构能力各域本是相通的。
架构能力：各域的HPC选型、外设选型在技能上趋同，亦可合并在一起。而SOA、EEA架构更多的考虑的是功能的分配(灰盒与黑盒)、电力/线束的分配等功能，这两者协同合作更佳。
2.2 分阶段的研发路线图
上图中的“能力”区分较多，那么如何分步建立各领域的能力呢？下面是一个优先级及顺序建议。
阶段0：EEA架构能力是OEM的基础能力，此处就不做强调了，除非没有量产经验，否则这是必需的。
阶段1：OEM首先应该做的，就是挑某个领域开始自研，这样可以拉通“需求与设计”、“代码编写”、“软件架构”这三方面的能力。
阶段2：在自研1~2年后，或者开始第二个量产项目之后，会发现软件用于适配各种硬件的工作量越来越多，所以，应该在“自研”之后，建立系统架构能力，尽量做到“硬件平台化”，以及“硬件可升级”的目的。
阶段3：把“SOA架构能力”放在最后一阶段实属无奈，因为它需要基于Ethernet来建立,且各域最好都已有自研部分，否则推动供应商实施会较难。它可实现的功能太多，比如可使能整车软件功能的“按需购买”、3月一迭代变成1月一迭代，大幅提高软件复用度等等
职能部门的数字化：再次强调一遍，这件事情需要一直进行，以给研发更好的支持，不拖后腿。
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+：不推荐自研，理由与智能座舱的一致。
2.4 阶段二：系统架构能力建设
系统架构示例
2.5 阶段三：SOA架构能力建设及问题
(1)SOA架构设计原则 在Ethernet作为主干网进入整车后，SOA就成必然选项。其将给整车的软件开发及迭代带来质的飞跃。
(1) 在整车各服务的拆分时，如何做到高内聚、低耦合？
这个答案其实非常简单，只要遵守分布式系统软件架构设计的设计原则即可，网络上有很多资料。以下是一些个人见解，并以“人脸识别”为例，做了详细的阐述：扩展性：目前这套人脸识别代码只能支持本地存储99张人脸，是否有存储更多人脸的需求？如果有的话，可能就要采用云端与本地同步存储的方案。对外提供的接口也会不同，如增加“同步人脸中”的对外状态。
可靠性：人脸识别的准确率为99.9%，误识别率为0.1%。如果用在车内做个性化坐椅调节没问题，但用于“支付”，这个可靠性就不够，需要更换方案。
性能：人脸识别所需时间需为0.5秒。那么在这个场景中，人脸识别服务与应用可以放在不同的域控制器中，用SOME/IP进行通信。但如果所需时间为0.1秒，人脸识别服务与应用，可能就要放在同一个程序中了。
异常/边界情况：人脸识别失效了怎么办？所以，人脸识别相关的应用必须定义额外的备用选项，使用其他的接口，如手动调节坐椅，输入密码支付等等。
可行性：来了个新需求，要求老板上车时播放定制化的欢迎语，明天必须完成。这时，就不能增加“定制化欢迎语”的功能，而只能在识别到老板后，写死欢迎语了。
所有服务都在Ethernet上共享了，那么如何管理权限呢？要不然以后一个第三方应用来直接控制我的方向盘咋办？
SOA可以让功能迭代时，各方的工作量减少，加快迭代的速度。但难道每次都走劳民伤财的FOTA吗？
上线了一个付费购买的功能，但用户买了后，如何把功能打开呢？有没有统一的框架呢？
Identity Access Management：身份认证与权限管理，专治流氓程序
Update & Configuration Management: 支持应用升级，月月迭代不是梦；支持远程配置，让买买买更顺滑！
3
总结
再次申明一下：上述的路线图以及自研范围推荐，皆仅供普通OEM参考，土豪请随意！ 到此，已经回答了前面的两个问题：OEM的自研范围：要自己搞软件，应该搞哪些呢？
回答：智能座舱、智能驾驶、车辆控制各有不同的策略
软件如何持续迭代：搞了这么多软件，怎么保证它能快速、持续的迭代呢
回答：系统架构上做到硬件可升级，整车软件架构支持SOA
—
END—
技术交流群：YasmineMiao(微信)
投稿合作：18918250345(微信)
扫一扫
551
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
