软件定义汽车5-中央计算单元架构

前几篇内容更多是从全局的视角阐述软件定义汽车，但写这个系列并不只是为了介绍软件架构，也不是为了给大家推销理念或普及概念，而是为了构建一张完整的全系统知识图谱，系统性的探讨在实现过程中的各种技术问题。按照我的想法，后续工作将按以下两个阶段进行：1．设计阶段；2．开源实施阶段。

第一阶段通过系列文章以及和大家的交流讨论，梳理要解决的关键问题，确定解决这些问题的技术路径，设计关键组件的技术架构。

第二阶段将着手搭建关键软件组件的代码框架。＂Talk is cheap， show me the code＂ ，对我而言，架构设计不只是画几张图就完事了，搭建一个基础的代码框架，也是保证架构设计能够快速推进的有效手段之一。如果你是软件产品设计、架构设计、程序设计的高手，又对开源软件感兴趣，可以在后台留言，这种局面是有机会做点事情的，兴趣驱动无任何商业目的，欢迎各路geek参与讨论！

在科技圈工作久了的人，估计也很难理解，为啥汽车行业会形成这种群雄割据的状态，汽车软件的封闭性，看似给这个行业构筑了壁垒，实际上也限制了整个行业生态的发展，开源软件造就了今天人工智能行业的繁荣，但一眼望去，整个汽车软件行业依然一片沉寂，都知道软件很重要，可是符合行业要求的人才从什么地方来呢？

构建一个面向车载的全栈软件参考方案，思考并解决各个组件在车载环境下面对的挑战（实时可靠、功能安全、信息安全），一方面为各方提供一些参考设计和思路，另一方面也为刚入门的行业初学者领领路，软件方面将重点围绕以下主题展开：

车载RTOS系统Hypervisor虚拟化分布式通信框架分布式服务开发框架分布式计算框架 中央计算单元的架构

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

EEA 构型．jpg

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

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

中央计算单元构型．jpg

中央计算单元可以分为以下三种形态：分离式硬件隔离式软件虚拟式

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

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

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

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

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

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

结语

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

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