软件定义汽车：架构分析

前言：

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

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

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

full stack architecture  这张图是以A4纸的尺寸来进行绘制的。建议下载下来放大来看，原图我会放在汽车电子软件公众号的后台，大家可以在微信后台输入 “架构总览” 获取。 画这张整体架构图，其实有以下几个目的：

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

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

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

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

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

架构总览

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

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

• 可拓展硬件计算平台

• 操作系统内核

• 分布式服务中间件

• 标准化服务层

• 可编排应用层

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

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

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

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

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

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

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

 主要目的是，提供一个与车型无关的统一平台，在此之上构建的所有车型都将采用统一架构。可拓展中央计算平台与模块化Zonal Controller 是构建这个标准电子架构的核心。中央计算单元将整合自动驾驶，智能座舱和车辆控制三大域的核心业务功能，标准化的区域控制器主要有三个职责：

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

所谓的标准化区域控制器，是指所有的Zonal Controller都采用相同的硬件设计，拥有相同的IO接口。可以根据车型的需要灵活的去配置三个，四个，甚至更多的区域控制器，以满足不同车型对于拓展性的要求。 central+zonal 中央计算单元与区域控制器之间都会采用高速以太网相互连接。因此，中央计算单元将会集成一个高吞吐量的以太网交换机。为了满足车辆控制实时性的要求，核心网将会采用如TSN等的可靠通讯技术。在区域控制器下的局域网内，传统的CAN、Lin等通讯方式将会继续存在。局域网内可以以传统的信号的方式进行通信，在核心的以太网骨干网络中，将会以服务的方式进行数据之间的交互，就需要如DDS等通信中间件。 随着整车集成化的程度越来越高。越来越多ECU的功能将会慢慢的被吸收到区域控制器当中。所以，区域控制还同时承担，整车硬件抽象的重要职能，这一块在介绍服务层中的原子服务时会详细说明。 概括来讲，可拓展的电子架构就是要屏蔽车型之间的硬件差异。不管采用多少个区域控制器组成的通讯网络，其相互之间的通讯模式，都遵守同样的规则。同时区域控制器也承担其局域网内，ECU功能的抽象之责。

2. 可拓展中央计算平台

 中央计算平台需要拥有统一的传感器及外设接口，同时需要能够兼容各家的芯片产品。随着整车智能化的提高，越来越多的芯片玩家进入到了车载芯片领域，在此之前，车载芯片的迭代速度非常慢，然而最近几年，车载芯片的迭代速度越来越快，各种高性能的芯片层出不穷。 如果每次换芯片都要进行换骨手术，对整个技术架构进行重构，会极大的拖慢新产品的开发速度。目前来看，车载芯片的发展速度，正在向消费电子靠近，消费电子领域基本是一年一代芯片。车载领域虽然稍微慢一点，但是升级换代的诉求也非常强烈。 关于中央计算单元的架构方式，之前的文章已专门做过阐述，有三种方式：分离SOC、硬件隔离、软件虚拟化，详细可参考这篇文章， 《中央计算单元架构》 总结下来，中央计算平台需要拥有统一的传感器及外设接口，同时能够支持芯片的升级，其最终目的就是要实现在车生命周期内的硬件可升级，从而延长汽车的智能化生命周期。

3. 操作系统内核

 关于操作系统的概念，之前的文章已经辨析过。目前各种操作系统的概念满天飞，但大部分都只是操作系统中间件。由于车辆的复杂性以及对于实时性的要求，没法用一个操作系统来统一所有的应用场景。这并不是一个软件问题，在此不做过多阐述，详细参考这篇文章， 《软件定义汽车-概述》 在操作系统内核层面，最主要的就是要满足实时性的要求，能够保证系统的性能和稳定性。如果需要采用虚拟化的方案，很多虚拟化的工作也需要在这一层展开。这块不是车厂的强项，也不是能够体现产品差异化的地方。因为无论用谁家的，其实现的功能都非常相似。所以没必要车厂单独去开发一个内核，本身很多生态的建设靠车厂也无法完成，这个工作交给科技公司去做就好了，有很多成熟的可选的方案。 在上面的图中，也有一种类型的系统叫OS for MCU，最典型的就是Classic AutoSAR。从这个整体架构图当中，大家也可以看到，它的生与死其实根本就不关键。因为它只是整个计算系统当中非常小的一块儿。所有的代码量加起来也就几兆大小，对它的需求是成熟稳定，可用即可。在中央计算架构下，以太网是核心的通信方式，传统的MCU的网络管理、CAN通信、诊断等功能，将会被中央计算单元所吸收。未来中央计算单元的MCU承担的最主要的职责可能是电源管理。

4. 分布式服务框架

 很多人也把这层称为XX.OS，其本质上是一个操作系统中间件。 其最核心的作用，就是提供一个分布式的计算和通信框架。 对下屏蔽各类操作系统内核的差异，对上提供统一的服务开发框架。 其主要包含服务管理、网络管理、通信管理、升级、诊断、日志、状态等。Adaptive Autosar和ROS就是典型的分布式服务开发框架，此类中间件都是解决通用的技术问题，实质上也不是车厂的核心竞争力，当然有余力的也可以选择自己开发，详细可以参考这篇文章， 《SOA基础软件框架与参考实现》

5. 标准化服务层

 也有很多人把在这层也称之为XX.OS，其主要目的是把车上，硬件功能抽象为各种服务，并且进行分类分层，为上层应用提供良好的开发SDK。在上图的架构中，分为四层设计：

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

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

6. 可编排应用层

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

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

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

结语

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