引言
前几篇更多是从全局的视角阐述软件定义汽车，但写这个系列并不只是为了介绍软件架构，也不是为了给大家推销理念或普及概念，而是为了构建一张完整的全系统知识图谱，系统性的探讨在实现过程中的各种技术问题。按照我的想法，后续工作将按以下两个阶段进行：
- 设计阶段
- 开源实施阶段
第一阶段通过系列文章以及和大家的交流讨论，梳理要解决的关键问题，确定解决这些问题的技术路径，设计关键组件的技术架构。
第二阶段将着手搭建关键软件组件的代码框架。“Talk is cheap, show me the code” ，对我而言，架构设计不只是画几张图就完事了，搭建一个基础的代码框架，也是保证架构设计能够快速推进的有效手段之一。如果你是软件产品设计、架构设计、程序设计的高手，又对开源软件感兴趣，可以在后台留言，这种局面是有机会做点事情的，兴趣驱动无任何商业目的，欢迎各路geek参与讨论！
在科技圈工作久了的人，估计也很难理解，为啥汽车行业会形成这种群雄割据的状态，汽车软件的封闭性，看似给这个行业构筑了壁垒，实际上也限制了整个行业生态的发展，开源软件造就了今天人工智能行业的繁荣，但一眼望去，整个汽车软件行业依然一片沉寂，都知道软件很重要，可是符合行业要求的人才从什么地方来呢？
构建一个面向车载的全栈软件参考方案，思考并解决各个组件在车载环境下面对的挑战(实时可靠、功能安全、信息安全），一方面为各方提供一些参考设计和思路，另一方面也为刚入门的行业初学者领领路，软件方面将重点围绕以下主题展开：
- 车载RTOS系统
- Hypervisor虚拟化
- 分布式通信框架
- 分布式服务开发框架
- 分布式计算框架
*计算单元的架构
完整的数字系统架构，是软件定义汽车的技术基础，应该是由，电子电气架构+计算单元硬件架构+软件架构三部分组成。
图 EEA 构型
传统的整车部门也会有电子电气架构，其涵盖的内容很广，但是数字系统更多的关注通信与计算的部分，两者是一个互补的合作关系。在Domain向Zonal发展过程中就产生了一个分水岭，Domain之前传统的EEA部门就能完全应对，Zonal 之后由于新增了大量的软件开发工作，需要与软件团队高度合作。
今天讨论的重点不是EEA架构，而是其中最关键的部分，*计算单元，不管是按区域的架构，还是以后的纯*计算平台，其硬件构型从根本上决定了软件架构的设计方向。
图 *计算单元构型
*计算单元可以分为以下三种形态：
- 分离式
- 硬件隔离式
- 软件虚拟式
分离式是指，将多个不同的芯片集成到一个*计算单元上去，每个运行不同的操作系统，只是在形态上集中到了一起，各单元依然独立的完成各自任务，代表如特斯拉AP，奥迪zFAS等。
硬件隔离式是指，在统一的计算平台上采用虚拟化方案，同时运行多个操作系统，但是各个系统依然在硬件上进行隔离，每个系统都有自己的专属硬件资源。
软件虚拟式是指，在统一的计算平台上采用虚拟化方案，同时运行多个操作系统，每个操作系统所使用的硬件资源，由Hypervisor层动态调配，每个系统并没有专属的硬件资源。
分离式最大的好处就是功能边界清晰，相比于传统的独立的BOX，只需要在电路设计上，把每个芯片放在不同的PCB板，然后将多块PCB叠加在一起。坏处就是，硬件资源浪费，每个芯片都需要一个最小系统，并且硬件上还没法拓展。
硬件隔离式和软件虚拟式，都采用了虚拟化方案，唯一不同点在于硬件资源是否专属，如果是专属的，就意味着资源无法动态调配，容易产生资源浪费。 虚拟化方案最大的好处是，硬件上的可拓展性，如果*计算单元采用刀片式的设计结构，可以很方便的拓展计算单元的算力，而不用替换整个计算单元。
谈到Hypervisor虚拟化，大家最大的顾虑就是稳定性，其实在*计算单元中，只需要两个操作系统即可，用于自动驾驶、车控、网关的RTOS，以及用于娱乐的普通OS（如Android、Linux）。用于娱乐的OS完全可以通过虚拟机的方式运行，用于自动驾驶、车控、网关的RTOS，可以直接运行在Hypervisor层，这样在兼顾实时计算的要求的前提下也能获得丰富的娱乐系统功能。
结语
前面几篇介绍了面向服务的架构设计SOA，但是SOA其实只是解决了软件定义汽车中的一个问题，即服务的开发、通信等问题，他只是整个技术栈当中的一环，而且也并不是解决这个问题的唯一途径。
收到了一些专家的反馈，他们认为应该从更高的维度去阐释软件定义汽车，架构设计中，不仅要包含车载计算，还应考虑其与云端、边缘端等的关系，所以接下来将从底层的基础系统入手，逐步向上拓展，将这个分布式系统的范围进一步扩大。本篇只是开了个头，下一篇将重点探讨，Hypervisor虚拟化技术在基础系统架构中的应用。