中央计算单元架构

一、中央计算单元的架构

完整的数字系统架构，是软件定义汽车的技术基础，应该是由，电子电气架构+计算单元硬件架构+软件架构三部分组成。

传统的整车部门也会有电子电气架构，其涵盖的内容很广，但是数字系统更多的关注通信与计算的部分，两者是一个互补的合作关系。在Domain向Zonal发展过程中就产生了一个分水岭，Domain之前传统的EEA部门就能完全应对，Zonal 之后由于新增了大量的软件开发工作，需要与软件团队高度合作。

今天讨论的重点不是EEA架构，而是其中最关键的部分，中央计算单元，不管是按区域的架构，还是以后的纯中央计算平台，其硬件构型从根本上决定了软件架构的设计方向。

中央计算单元可以分为以下三种形态：

分离式

硬件隔离式

软件虚拟式

分离式是指，将多个不同的芯片集成到一个中央计算单元上去，每个运行不同的操作系统，只是在形态上集中到了一起，各单元依然独立的完成各自任务，代表如特斯拉AP，奥迪zFAS等。

硬件隔离式是指，在统一的计算平台上采用虚拟化方案，同时运行多个操作系统，但是各个系统依然在硬件上进行隔离，每个系统都有自己的专属硬件资源。

软件虚拟式是指，在统一的计算平台上采用虚拟化方案，同时运行多个操作系统，每个操作系统所使用的硬件资源，由Hypervisor层动态调配，每个系统并没有专属的硬件资源。

分离式最大的好处就是功能边界清晰，相比于传统的独立的BOX，只需要在电路设计上，把每个芯片放在不同的PCB板，然后将多块PCB叠加在一起。坏处就是，硬件资源浪费，每个芯片都需要一个最小系统，并且硬件上还没法拓展。

硬件隔离式和软件虚拟式，都采用了虚拟化方案，唯一不同点在于硬件资源是否专属，如果是专属的，就意味着资源无法动态调配，容易产生资源浪费。虚拟化方案最大的好处是，硬件上的可拓展性，如果中央计算单元采用刀片式的设计结构，可以很方便的拓展计算单元的算力，而不用替换整个计算单元。

谈到Hypervisor虚拟化，大家最大的顾虑就是稳定性，其实在中央计算单元中，只需要两个操作系统即可，用于自动驾驶、车控、网关的RTOS，以及用于娱乐的普通OS（如Android、Linux）。用于娱乐的OS完全可以通过虚拟机的方式运行，用于自动驾驶、车控、网关的RTOS，可以直接运行在Hypervisor层，这样在兼顾实时计算的要求的前提下也能获得丰富的娱乐系统功能。

二、结语

前面几篇介绍了面向服务的架构设计SOA，但是SOA其实只是解决了软件定义汽车中的一个问题，即服务的开发、通信等问题，他只是整个技术栈当中的一环，而且也并不是解决这个问题的唯一途径。

收到了一些专家的反馈，他们认为应该从更高的维度去阐释软件定义汽车，架构设计中，不仅要包含车载计算，还应考虑其与云端、边缘端等的关系，所以接下来将从底层的基础系统入手，逐步向上拓展，将这个分布式系统的范围进一步扩大。本篇只是开了个头，下一篇将重点探讨，Hypervisor虚拟化技术在基础系统架构中的应用。

开发人才从何而来

引言：从2019年下半年开始，各个玩家都发布了在汽车软件化方面的战略，特别是2020年这种经济大环境不好的情况下，仔细去看看各方的动作，丝毫感受不到有什么汽车业的寒冬，有些玩家是真做，有些玩家是在跟风，还有一些还在睡觉。

最近和各种背景的人交流，技术派似乎认为这就是未来方向，传统派关注的问题很实际，花这么大代价去重构汽车的软硬件基础架构，究竟有什么意义？对这个方向还存在疑虑的，现阶段也很难有什么令人信服的证据去说服。我更加关注执行层面的事情，如果这个方向的是正确的，如何能让想法慢慢落地？思考了很久，决定从三个维度去阐述这个事情：

人从哪儿来

要做的事情

执行策略与计划

为什么先讲人，是因为软件定义汽车这件事情，最关键的还是要重构车辆底层的软硬件基础架构，而行业里面没有现成的人才储备，无论是互联网来的，还是传统汽车电子软件来的，都存在能力上的短板，并且从架构上也没有最佳实践，所以即使是哪家车厂想清楚了要做什么，短时间也招不到如此多的合格的人才，所以传统的玩家无论想做什么软件，三个基本能力是必须掌握的：

软件架构能力

软件开发能力

软件工程的能力

很多人都在讲，传统巨头转型过来，会吊打特斯拉，可事实是转型过来的巨头依然还在被吊打着，有一个要素大家要清楚，拥有强大软件的研发能力的科技巨头，招揽汽车顶级人才的能力，要明显强于传统巨头招揽软件人才的能力，科技巨头拿二线程序员的薪资就能招揽到一线的汽车人才，虽然很残酷，但却是事实。

一、互联网人才的能力模型

IT与互联网大部分的软件开发人员，都属于在通用计算机系统上的软件开发，一般是在某种操作系统上(Windows/Linux/IOS等）进行应用软件开发，主要包含电脑端，手机端，服务器端等设备，以X86与ARM架构为主，大部分开发人员都会使用某种高级语言进行特定任务的开发(C++/JAVA/OC//JS/PYTHON等），由于业务的需要，互联网公司会有算法人员(图像/语音/数据），手机与智能硬件的公司，也会有部分BSP的开发团队，他们属于软件团队中最懂电子硬件的人。

大部分计算机相关专业的人，毕业之后都涌入了这个行业，部分非计算机相关专业的人，自学编程之后也涌入了这个行业，所以这个行业当中有庞大的人口基数，人员规模在百万以上。

从2015年开始，掀起的智能网联和自动驾驶的热潮，吸引了大批互联网人的加入，从本质上讲，都是围绕车的外围进行的一系列应用开发（ 车机+TBOX+手机+服务器），但车还是那辆车，基础架构并没有发生变化。通过几年的摸索，大家也发现，只在外围做创新，本质上无法带来革命性的突破，不去从内核上革命，永远也追不上特斯拉。

总结下来，我的观点可以概括为以下几点：

互联网有大量的优秀软件人才储备，有构建大规模软件的软件工程经验。

搞车联网和自动驾驶，互联网人有技术上的优势。

但是大部分人不懂硬件，需要补上硬件的短板，以及汽车软件的Know-How。

IT界在成熟硬件架构的上的工程的经验，照搬到车这个分布式异构平台下是要吃亏的。

按照过往的经验，车载软件一半以上的时间花在了集成联调阶段，不像互联网测试环境到生产环境的迁移那么的流畅。

二、传统汽车人的能力模型

传统车企里面最懂软件的应该就是其IT信息部门了，这两年兴起的车联网，车企中最先参与的也是这部分人，但大部分的开发人员还是都来自于IT及互联网。

传统汽车产业链当中对软件了解最多的，应该是Tier1当中的汽车电子软件部门，汽车电子软件属于嵌入式软件开发范畴，是在专用计算机系统上进行软件开发，一般要求开发人员具有一定的硬件基础，主流的嵌入式平台包含ARM、DSP、FPGA等，开发语言主要是汇编/C/C++，受限于整个行业的限制，汽车电子软件的主流开发平台还是ARM，并且大部分还局限在微控制器层面。

大部分的嵌入式软件开发人员，来自于通信、自动化、电子等对电子硬件比较了解的专业，少部分来自于计算机（嵌入式只是计算机专业的一个小分支，毕业生更倾向于去互联网），汽车电子软件属于嵌入式软件的一个分支，但由于其行业的封闭性，从业人员的来源就更窄，前面的文章也分析过，如果除掉车联网的那批人，中国整个行业不超过5000人。

从软件人员的角度看来，和整个软件关系最大的可能就是电子电气架构，可是在传统车企那里，电子电气部门的话语权也是受限的，观察一下各大车企技术中心研究院的负责人，基本都是传统底盘、发动机等领域出身。在他们的领导下搞软件定义汽车，搞数字化系统，想想就知道结果，所以组织架构的变革是前提。

三、传统ECU的开发模式

很多文章都提到传统ECU，一辆现代汽车会包含几十到上百个各种各样的ECU，虽然数量很多，但是构型基本一样，以下就是传统ECU的典型架构图：

主要包含以下几个部分：

电源、外设接口、ADC、SCI、PWM、看门狗、车载网络接口(CAN、LIN、Ethernet、FlexRay）

非易失性存储NVM（一般在几十K到几兆之间，大部分应用512K以内就足够）

SRAM（一般在几十K到几兆之间，大部分应用256K以内就足够）

一般具有以下特性：

采用Cortex-M、Cortex-R内核居多，部分厂家有自己的内核

Lock-Step(保持多个CPU、内存精确的同步，在正确的相同时钟周期内执行相同的指令)

ECC、ECM 纠错机制

最高能够达到ASIL-D 安全等级要求

代表芯片：

NXP S32K系列 MAC系列 LPC系列 KEA系列 i.MX RT系列 （都是Cortex-M内核）

英飞凌 XMC系列(Cortex-M内核） AURIX TC系列（TriCore内核）

瑞萨 RH850系列

TI Hercules系列(Cortex-R内核）

一个不跑任何操作系统的ECU，其主程序代码一般如下：

在运行到主程序之前，会有一系列汇编代码，处理与CPU体系架构，板级支持相关的事情，一般会包含，屏蔽中断，初始化内存，建立堆栈，把代码搬进内存等等，事实上就是BootLoader该做的事情。

这样写的裸机程序，其任务只能顺序执行(可以通过更改PC指针强制跳转），也可以通过中断执行其他任务，但是却无法灵活的设定任务的优先级，适合于任务非常简单的场景，比如在单核处理器中，做简单的开关控制。

稍微复杂一点的场景，就需要有一个OS来实现相关的设备管理，比如小型RTOS，其主程序代码框架一般如下：

这个OS最核心的功能就是提供了任务调度、优先级设定、任务间通信的机制，在OS之上就能实现更加丰富的业务逻辑。

如果是遵守Classic AutoSAR的方法论进行开发，整个过程可以分为三个阶段：系统配置、ECU设计与配置、代码生成，开发过程中会使用由Vector公司等公司提供的工具，前期也会在MATLAB Simulink中进行仿真，最后生成项目代码，在这个过程中几乎不用写什么代码。

所以概括下来，有以下几点想表达：

传统ECU软件的开发，也并不像大家想的那样高门槛，本身也不复杂，再复杂也就几百K的代码量，还不如高性能计算单元上的一个引导程序大。

汽车电子软件的核心工作就是与硬件设备交互，开发语言是汇编和C，只做业务会C语言就行了，汽车软件的特殊Know-How是这个行业的一个壁垒。

大部分嵌入软件工程师都精通C编程，但也被C面向过程的思维限制住了，缺少的是构建大规模软件的软件工程能力。

传统的嵌入式软件开发，可以为汽车这个行业提供许多人才储备，过来的人员需要补齐车载软件开发的Know-How。

四、高性能计算单元上的软件开发

这个章节我先起个头，因为这部分内容和软件定义汽车具体要做的事情非常相关，下图是TI的TDA4的系统框图，非常典型，各家的高性能SOC也都大同小异，大家先看看，有个印象，下篇我们将详细介绍。

高性能计算单元

五、总结

对于无论是互联网人，还是传统的汽车电子软件开的人员，软件定义汽车都是一个新的领域，需要相互借鉴、相互学习，想要加入这个行业的人需要补齐对应技术上的短板，对于各个玩家来说，现阶段还是以积累能力为主，而且招募相关人员会非常困难，特别是能够进行全局设计的架构人员。

每个行业都有每个行业的专业性，得心存敬意，但也不是畏惧，为什么有底气说这些，也是有经历的因素在里面，童年时代大家在玩玩具的时候，这些芯片电子元件就是我的玩具，后面的各种项目经历，使得我对各家芯片也是如数家珍，这种经历也为我现在做架构工作提供了非常大的优势，因为一般的开发工程师或者是合作方很难找理由忽悠住我，实在不行我会直接教他怎么做。

希望有更多软件领域的高手投入到这个行业，做这个事情需要很强攻关能力的技术团队，也需要全行业一起努力！

高性能计算单元架构

引言：前一篇文章中介绍了传统ECU的特点及开发模式，在中央计算电子电气架构下，中央计算单元都会采用高性能的SOC来作为主运算单元，由于其资源的丰富性，其开发模式和开发的复杂度，相比与传统的ECU都大有不同，因此，对应的软件架构（逻辑，物理，运行，部署等架构视图）、软件工程中各个环节（设计、开发、测试、部署等过程）都不相同。本篇主要介绍中央计算单元的软件架构，阐述各个软件模块主要工作任务。

一、 高性能计算单元

中央计算单元，其实就是一台经过特殊设计的专用计算机，其中最核心的是主芯片，一般会采用一颗或多颗高性能的SOC。SOC是System on Chip的缩写，就是在单块芯片上集成多个微处理器、模拟IP核、数字IP核和存储器等部件，比如CPU、GPU、DSP、ISP、Codec、NPU、Modem等模块。

在传统PC时代，各个核心芯片都是以独立的方式存在，比如英特尔和AMD的CPU、NVIDIA的GPU等，到了移动互联网时代，由于体积功耗方面的要求，主芯片都会进行高度的集成，除了大家熟知的CPU和GPU，通常还包含了音频、多媒体、显示、安全、通信、AI计算等子单元。

这些单元，在一套总线系统的连接下，构成了一个系统。大家所熟知的各种手机SOC芯片，如苹果的A系列、高通的骁龙系列、华为的麒麟系列，或者各类的AI SOC芯片，车载领域的各种SOC芯片，都逃不出以上范式。

虽然都是同一范式，但是由于使用的场景不同，各个芯片的侧重点不太一样：

娱乐系统芯片，其实和消费电子几乎一模一样，关注音频、视频、显示、图像等、Modem等。

自动驾驶芯片，注重高性能计算，一般配备有强大的NPU、GPU、DSP等。

网关芯片，主要特点是外设接口较多，有的也会集成swtich。

高性能计算单元.png

上一篇中，为大家介绍了传统ECU芯片的架构，其计算资源相对有限，结构也比较简单，一般NVM和SRAM都集成在了芯片内部，大小在KB级别，处理器一般采用Cortex-M内核。高性能的SOC其计算资源和外设都更加丰富，一般会集成多个Cortex-A内核，其存储单元采用外挂的形式，大小在GB级别。

一般的应用场景中，集成一个主芯片就能够满足计算资源的需求，但是自动驾驶对算力有着更高的要求，有时候 于安全的考虑，也需要同时集成多个主芯片，其结构一般如下图所示：

多个芯片在需要在PCIe Switch的连接下共同组成一个计算单元，如果以后发展成可动态拓展的形式（类似于刀片机），该结构依然适用，以下是采用两个Xavier芯片组成的一个高性能计算单元的示意图：

二、中央计算单元上的软件架构

高性能计算单元上是需要运行操作系统的，如果完全用裸机程序去控制，几乎无法完成。从下到上，依次可分为以下几个部分，硬件驱动层，操作系统内核，分布式中间件，并行计算中间件，应用及服务。

硬件驱动层(BSP)

在嵌入式软件开发当中，软件工程师经常要直接和硬件进行交互，但是在高性能计算单元上，由于有富操作系统的存在，这部分工作一般由BSP工程师完成。

BSP（Board Support Package）板级支持包，是介于硬件和操作系统中驱动层程序之间的一层，一般认为它属于操作系统一部分，主要是实现对操作系统的支持，为上层的驱动程序提供访问硬件设备寄存器的函数包，不同的操作系统对应于不同形式的BSP，尽管实现的功能一样，可是写法和接口定义是完全不同的，BSP的编程过程大多数是在某一个成型的BSP模板上进行修改，芯片厂商一般会基于其开发板，提供一个可运行的软件基线，开发厂商基于该基线进行修改。

BSP的调试工作是和硬件强相关的，目前普遍会选择由硬件Tier1做掉这部分工作，由于本身的技术壁垒不高，所以有余力的玩家选择自己做也完全不是什么问题。

操作系统内核

在软件定义汽车1-3合集中，我对操作系统的概念做过辨析，为了避免歧义，这里我直接称操作系统内核，很多玩家所谓的做自己的操作系统，其实都只是内核之上的中间件。这部分不是主机厂该做的事情，用QNX、Vxworks、Linux、FreeRTOS等，或者以后的鸿蒙微内核即可。虽然这种不直接面向C端用户的操作系统对应用生态的要求不高，但是对于开发者生态的要求还是挺高的。使用这些操作系统的时候，有几个因素至关重要：

POSIX兼容性

工具链

POSIX是一个操作系统的接口标准，如果一个操作系统对于POSIX兼容性好，那么开源世界中的很多软件模块是可以复用的。举一个例子，cocos2dx 是一个开源的游戏引擎，支持windows、Linux、Mac等系统，不支持QNX系统，但是由于QNX系统良好的兼容了POSIX，我们只花了很少的功夫就把其移植到了QNX上，虽然cocos2dx依赖了好几十个开源的软件库，但调用的都是标准的POSIX接口，所以也都能非常方便的进行移植。有些网关开发中会使用FreeRTOS，其也有专门的拓展库来支持POSIX调用。

举一个反面的例子，Halide是一个专用的图像处理引擎，其构建是基于LLVM编译器框架的，由于QNX官方支持的编译器是基于GNU GCC的，我曾经尝试过要把Halide移植到QNX，但是由于编译器不支持，迁移过程就碰到了很大的困难。所以系统所支持的编译器框架，也决定了很多最新的开源项目是否能被使用。

传统主机厂，不喜欢开源软件，其中最重要的一个原因，是其技术实力太弱，出了问题自己无法解决，但是新的科技玩家，会更加的拥抱开源软件。

主机厂自己做软件，虽然不用去碰内核，但是必须有几个系统方面的高手，主要是应对系统的稳定性问题，这个对于安全性较高的控制器尤为重要，软件进度上的问题堆人力可以弥补，但涉及到架构、性能、稳定性、安全等，做这部分工作就不是靠堆人力能解决的。

分布式中间件

参考软件定义汽车1-3，所谓的分布式中间件，就是在实时的RTOS内核上，基于POSIX的API，构建的一个跨平台的操作系统中间件，为上层的应用提供良好的计算、通信的开发框架，其作用类似于Android的Framework，只不过主要是针对实时、高可靠性应用场景的。

这类Framework中间件，有三个核心要素：

Library（提供一系列基础库，封装特定功能）

Service （独立运行的基础服务节点，作为逻辑处理的后端）

SDK （为上层应用提供良好的API接口）

从功能上讲，这类Framework中间件，一般需要包含以下功能：

包管理（应用管理）：基于基础软件平台开发的上层应用，在编译之后会被打成一个应用程序包，在这个包中一般会有一个manifest文件，该文件声明该包的版本，依赖，所需权限，生命周期，启动选项等。当该应用安装到系统中的时候，包管理程序会解析该manifest文件，得到的元数据会保存到数据库当中，这些数据是后续该应用能够正常运行，正常升级的关键。

运行管理：系统在启动阶段，各个应用程序需要按照预先定义的启动顺序被拉起来；在运行阶段，管理程序需要记录当前应用的状态，处理应用生命周期的各种事件。比如手机和PC程序都会有前台应用的概念，当打开、关闭、重启、切换等事件发生的时候，系统的运行管理程序都会发送一个消息给应用，让其做好相应的处理工作。不同的点在于，面向消费者的操作系统，都是可以让用户操作的，所以大部分的逻辑是与人机交互事件有关的，而面向车辆底层的系统，更多的是在后台处理相关的事件请求，其设计策略与逻辑完全不同。

通信管理：运行在分布式系统上的各个应用程序，是需要进行数据交互的，这就需要一类IPC/RPC的框架来支撑；IPC是指本机间的进程通信，RPC是指跨机器的间的远程调用，在分布式系统当中这两种通信都会碰到。比如在linux中常用的dbus，Android中使用的binder，以及前面文章中提到的DDS与some/IP。作为一个基础软件平台，一般是不会把这些原始的通信方法暴露给上层应用的，Framework会有自己的API去屏蔽底层通信协议的差异，这在架构设计中很关键，决定了框架是否和某一通信中间件绑死。如果还在拿dds与someip的原始接口写程序，意味着根本就没有进行平台化设计。

权限管理：安全在车上是一个更加重要的问题，一个用户和应用程序具有哪些权限，应该是被严格控制的。在应用程序的manifest当中，一般会声明该程序具有哪些权限，权限管理程序会根据包管理程序解析的元数据来严格控制应用程序的访问权限。一些高安全等级要求的访问权限，一般还会需要经过特别签名，以此来防止一些非法应用获得系统权限。在类unix系统当中，权限系统一般会根据UID和GID为基础进行设计，但是在车载环境中，此类权限系统也还不够，还需要进行更加严格的权限控制。

升级管理：能够不断的进行软件升级是软件定义汽车的基础，传统的ECU，一般都会生成一个bin文件，是没有所谓的包管理程序的概念的，要升其实就是把整个分区给刷掉了。这种方式针对传统的ECU并没有什么问题，但是针对高性能计算单元，这种方式的效率就很低，刷KB级的数据和刷GB级的数据，完全不是一个概念。为了高效的进行迭代，平台升级和应用升级一定是需要分开。平台升级类似于手机的ROM升级，而应用升级类似于手机的APP升级，一个长周期，一个短周期。要实现这种升级方式，是需要一个良好设计的基础软件平台的，应用与系统必须彻底解耦，这对架构设计是非常大的挑战。很遗憾，国内目前没一家能够做到这个水平，大家都会拿车的复杂性说事，其实是因为设计上的短板造成的，国内的几个先驱公司都被这个事情所困扰。因为在前期发展的过程中，都只注重短期功能的实现，没有真正的在工程能力方面下功夫。

其他的还有像诊断、日志、持久化、加密等功能性的模块，就不一一展开，后续可以针对每一部分的设计进行详细阐述。

这类中间件的平台，是一个基础的工具，各家之间没必要重复造轮子，行业是有一个adaptive autosar，但是目前还远远不够完善，特别是在并行计算方面。不只是在车载领域，整个中国的软件行业就没有一家像样的中间件公司，和一些投资机构的朋友也聊到了这个问题，我认为最大原因还是这类产品属于工程产品，客户都更愿意看到一个完整的解决方案，而不是给他提供一个中间件，之前快的节奏让大家都只愿意做来钱快的事情，这些慢活儿也没有成长的土壤。

但是在目前的政治环境之下，这种情况似乎迎来了一丝改变，一些贸易冲突，也让大家意识到了，老老实实打基础还是挺重要的。中国汽车行业最大的问题在于，这些玩家都觉得自己挺牛逼的，谁也不买谁的单，都想自己搞一套，但是在这个事情上，真心不是哪一个能独自搞定的。所以我还是建议，大家能够联合起来做点事情，哪怕是投点钱支持一些创业公司搞开源，也比自己搞要靠谱。就算是一家主机厂发起了一个开源项目，大概率其他的主机厂也不会用，必须以中立的身份来做，才能获得大家共同的认可。

服务及应用层

参考软件定义汽车1-3， 在一个标准的基础软硬件平台之上，各家主机厂可以构建自己的服务和应用体系，这也是各家能够形成差异化的地方。针对不同的应用场景（智驾、座舱、网关、车控等），以及各自差异化的硬件设备，抽象一套属于自己的服务体系，SOA只是实现目的的一种方式，大家可以根据自己的理解去拆解、分层、分类，然后形成一套自己的SDK体系，以支持产品业务的快速迭代。

在此基础上，我也期待有一天，能在各个车厂之间形成统一的接口定义的标准，那样一个应用就能够部署到所有车上，这其实是在从Tier1的角度看问题，Classic AutoSAR就是在这个愿景上产生的，对主机厂来说，只要自己所有车型能够统一，就是一个伟大的成就了。

三、并行计算框架

随着自动驾驶与智能座舱的发展，大量的以视觉为主的传感器部署到了车上，产生的数据需要高算力的计算单元来处理，就需要一个并行计算的框架来支撑应用程序的开发与部署。原则上来讲，该框架应该属于上面介绍的分布式计算框架的一部分，主要是这部分内容与传统的应用框架不太一样，所以拿出来单独讲。

parallel processing.png

目前有各种各样的AI计算芯片，但总体上都是CPU+协处理器的基本构型；CPU可以是基于ARM的IP，协处理可以是GPU、NPU、DSP、FPGA等，这些异构的计算单元，都会有自己的指令集。CPU擅长于做逻辑处理，这些并行计算单元擅长于做高性能计算，汽车电子软件公众号之前有文章介绍这几种计算单元的差异，有兴趣的可以去了解。

工作原理

大部分SOC都会采用这种主+从的方式，比如NVIDIA采用是CPU+GPU，高通采用CPU+GPU+ NPU+DSP，TI也采用CPU+GPU+ NPU+DSP，赛灵思采用CPU+FPGA等。

开发人员写的程序，虽然都在一个工程当中，但是在编译阶段，通过芯片厂商提供的工具链，代码会被编译成为两个部分：运行在CPU上的，与运行在异构单元上的，芯片厂商会提供一个基础的通信框架，来处理这部分逻辑。

在程序运行阶段，这两部分程序都会被加载到内存当中，由于SOC的总线设计当中很容易做到内存共享，各个计算单元会各自读取运行的指令与参数，通过芯片厂商提供的RPC框架，主程序可以很方便与协处理器进行逻辑通信。

需要注意的是，高性能计算的并不仅是运行CNN网络，还有其他的很多计算任务需要用到并行计算，并且每种计算单元的程序开发模型都不太一样，如果每部分都需要开发人员自己去处理，开发过程会非常复杂。

比如NVIDIA提供CUDA库来支持GPU上的并行计算，在CUDA之上又构建了TensorRT来运行神经网络；高通提供的SNPE框架，能够支持任务自动调度到CPU、GPU、NPU、DSP之上。当前阶段，这些框架都是和芯片高度绑定的，目前还没有一个通用的框架来屏蔽所有的差异。

除了底层的运行框架不统一之外，上层的应用开发框架也没有一个统一标准。比如NVIDIA提供了DRIVE AV平台，用于支持使用自家芯片进行自动驾驶应用的开发；很多公司基于ROS开发原型系统；也有创业公司基于ROS2进行车规化改造；还有一些使用Adaptive AutoSAR进行开发，但这部分恰好是其短板。

这部分实现想统一的确有比较大的困难，因为与芯片架构强相关，现阶段AI芯片的种类五花八门，在硬件构型不统一的的状态下，只能先选择芯片，再决定技术架构。

四、结语

本篇从大的维度上介绍了高性能计算单元上软件架构的几个重要部分，每个一个部分其实都值得继续进行深入。硬件单元的不同，也会导致软件框架的设计出现一些特性差异，比如在一个双冗余的计算单元中，除了硬件的fallback设计，软件上如何进行fallback，可选方案有多种，也不是非此即彼的问题。