软件定义汽车：架构分析

前言：

汽 车的智能化和软件化，就像一个巨大的漩涡，吸引着各方势力卷入其中。 就像上一篇文章提到的一样，在大家构建软件能力过程中，一些危机也正在酝酿之中，在缺乏良好设计的框架下，一旦进入正常的车型迭代，就会被以前历史的版本束缚住手脚。 前面的系列文章从各个角度阐述了如何构建软件驱动的硬件平台能力：

• 《概述》
• 《面向服务的架构设计》
• 《SOA基础软件框架与参考实现》
• 《行业现状》
• 《中央计算单元架构》
• 《开发人才从何而来》
• 《高性能计算单元架构》
• 《构建开源软件生态系统》
• 《危机是如何酿成的》

我构思了很久，想以一种比较简明扼要的方式，展现出整个数字系统架构的全貌。花了很长的时间去梳理，终于有了下面这张图，现在看来，这是所有文章里面我最满意的一张图了，从整车的视角，展现出了如何去构建新一代整车数字化平台。 其实这也是一张作战地图，未来几年，群雄逐鹿，各方势力都将围绕地图中的各个主题进行展开。这张图比较清楚的展示出了如何去构建一个软件、硬件、车型平台相互解耦的系统。

• 技术在这场变革中很重要，但是不是最关键的，从全局的角度去思考打造体系化的能力，首先必须知道要做的事情是什么。

• 对于产业链上的朋友来讲也可以理解，究竟OEM客户需要什么，自己所提供的产品，扮演了什么样的角色。

• 对于投资圈朋友来讲，参考这张图可以了解到，感兴趣的投资标的究竟处在什么样的行业位置当中，想解决什么样的问题，未来想发展成什么样。

• 新平台的开发，技术链路非常长且复杂，所以我非常希望看到产业链上的各个环节能够形成合力。在这次变革当中，能够帮助到各方玩家，更快的完成架构的升级和转型。

• 整个工程就像一个庞大的战役，如果各方都能清楚，自己在这个战役当中的位置，作为执行者来讲，也能够发挥自己的主观能动性，去更加积极主动的解决相关问题，也能知道如何去配合上下游开展工作。

架构总览

整个架构可以总结为“6+4”：6层逻辑架构构建起了一个软硬解耦的系统；4层服务架构完成了服务的抽象与适配，建立了一个标准化的服务体系；六层逻辑架构包括：

• 可拓展电子电气架构，也叫计算与通信架构

• 可拓展硬件计算平台

• 操作系统内核

• 分布式服务中间件

• 标准化服务层

• 可编排应用层

这6层的架构设计，实现了软件、硬件、车型平台相互解耦，之前也介绍过可能会碰到的软件危机，而良好的架构设计是解决这其中很多问题的关键。总结下来，可以体现为以下几点：

• 基于标准服务的开发，能够提高应用的迭代速度，让产品经理更加深入的介入产品的开发过程。

• 分层的架构设计，便于进行分层测试与验证，减少集成测试的压力，问题发现的更充分，也能够提高版本发布的速度。

• 便于形成产品线和平台线的分工，产品线负责具体车型项目，平台线，负责构建技术中台。

• 可拓展的硬件计算平台，可以兼容多种传感器和外部设备，同时支持芯片和硬件的可升级。

• 可拓展的计算通信架构，可以加快车型开发的速度，平台能够快速地适配到新的车型之上，分层的结构，把车型之间的差异化缩到最小，能够减少后期多产品线维护的压力。

1. 可拓展计算与通信架构

• 电力分配
• 数据服务
• 区域 关

所谓的标准化区域控制器，是指所有的Zonal Controller都采用相同的硬件设计，拥有相同的IO接口。可以根据车型的需要灵活的去配置三个，四个，甚至更多的区域控制器，以满足不同车型对于拓展性的要求。 

2. 可拓展中央计算平台

3. 操作系统内核

4. 分布式服务框架

5. 标准化服务层

• 最下层是服务的适配层，运行在Zonal Controller之上，将对局域 内的ECU功能进行抽象化处理，面向具体车型的信 进行适配。
• 服务适配层向上对接的是原子服务，指的是硬件的一些基本功能，比如传感器、电机控制、门窗、车灯等，最基本一些操作。
• 在原子服务之上是逻辑服务，也称为组合服务，里面有一定的判断逻辑存在。比如打开车门，打开车灯，并不是在任何状态下都无条件执行，需要判断很多条件。
• 在逻辑服务之上是业务服务，和各域的功能联系的比较紧密。

服务的抽象也有一些方法论可以遵守，可以从原来ECU的信 出发，从下往上梳理，形成一系列原子服务。另外就是从业务功能出发，从上往下梳理，形成一系列的逻辑服务和业务服。关于SOA分类分层的介绍，可以参考这篇文章， 《面向服务的架构设计》 。 我想强调的是，服务层的设计其实是车厂的关键能力，因为无论是服务中间件还是操作系统内核，很多的Tier1都可以去做，因为这些都是一个纯技术性的通用工作。但是服务层的设计只有OEM厂商才能够做。因为任何Tier1都只能接触到其中的一部分，所以没法从全局的角度去设计整个服务的框架，而这一层最大的作用就是，提供一些灵活可重组的基础服务，以供上层应用场景的快速实现。为产品功能的快速迭代打下了很好的基础。

6. 可编排应用层

在服务层之上就是各域的应用功能，此处的“域”只是一个虚拟的概念，因为在中央计算的架构下，各域之间已经没有了明显的物理边界，逻辑上可以划分为以下四个：

• 自动驾驶
• 智能座舱
• 车辆控制
• 智能天线

前面几个都有过介绍，所谓的智能天线，其实就是集合了所有的与外界通信的功能，如BT、WIFI、NFC、V2X、5G等等。 一个产品的功能往往都是需要，各域的相互配合才能实现的，在之前的技术架构下，产品经理很难介入到整个产品功能的开发周期当中。因为技术架构过于复杂，更多情况下是系统工程师在主导。所以把服务层做厚，把应用层做薄，把底层架构做充分的解耦，可以让产品经理很深入的介入到产品功能的设计开发当中。 此时产品功能的开发已经不需要去关心底层中间件、操作系统、硬件、电子架构的的影响。基于服务层提供的SDK可以快速的开发出产品所需要的功能，这也是未来智能座舱和自动驾驶等产品功能快速迭代的一个技术基础。

结语

同样一个问题，有多种解决的途径，分析下来会有多种解决方案。但是需要做的事情分分类，也都殊途同归。所以右边的文字部分详细的列出了各块儿需要做的事情，可以供大家参考。每一个点都是非常庞大的主题，要讲清楚，需要花很长的篇幅。后续有机会我们将围绕这些工作，进行更加细致的阐述。 很多人也在问，有没有一些书或者成熟的方案可以借鉴，很难有，因为这是一个很新的领域，很多时候需要去创造产业链上没有的东西，所以正向的研发，正向的思考是非常关键的。一切从问题出发，正向去思考，分析解决这些问题的途径，自然而然的会形成一种比较一致的判断。技术方案其实是一个非常客观的东西，大家可以理性的去分析，也欢迎大家反馈自己的想法。 本来是准备写关于芯片定制化的一些思考，但是如果不解释清楚整个技术架构，讲芯片的定制化可能会让大家感到疑惑。其实在设计中央计算单元的时候，最大的挑战就是可用的芯片。目前没有一款芯片能够同时满足几大功能域的要求，只能用多个芯片拼起来。半导体行业其实已经有了从晶元级别去集成多个芯片的能力。