软件定义汽车（Software Defined Vehicles, SDV），软件改变着汽车的DNA，毫无疑问，软件对于汽车的重要性不言而喻，从2016年开始，自动驾驶的大潮来临之际，软件定义汽车已经作为一个趋势和方向，在汽车技术行业，包括工程师中讨论交流，硬件，软件，自动驾驶，汽车的未来在哪里？本文作者从自己的项目经历，所学所看，从不同的视角和角度给大家分享下软件定义汽车的一种解读，供大家学习参考！
从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的典型架构图：
图1：传统ECU架构图
主要包含以下几个部分：
电源、外设接口、ADC、SCI、PWM、看门狗、车载网络接口(CAN、LIN、Ethernet、FlexRay）
非易失性存储NVM（一般在几十K到几兆之间，大部分应用512K以内就足够）
SRAM（一般在几十K到几兆之间，大部分应用256K以内就足够）
一般具有以下特性：
主要代表芯片：
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。
上一篇中，为大家介绍了传统ECU芯片的架构，其计算资源相对有限，结构也比较简单，一般NVM和SRAM都集成在了芯片内部，大小在KB级别，处理器一般采用Cortex-M内核。高性能的SOC其计算资源和外设都更加丰富，一般会集成多个Cortex-A内核，其存储单元采用外挂的形式，大小在GB级别。 一般的应用场景中，集成一个主芯片就能够满足计算资源的需求，但是自动驾驶对算力有着更高的要求，有时候 于安全的考虑，也需要同时集成多个主芯片，其结构一般如下图所示： 多个芯片在需要在PCIe Switch的连接下共同组成一个计算单元，如果以后发展成可动态拓展的形式（类似于刀片机），该结构依然适用。 以下是采用两个Xavier芯片组成的一个高性能计算单元的示意图：
高性能计算单元上是需要运行操作系统的，如果完全用裸机程序去控制，几乎无法完成。从下到上，依次可分为以下几个部分，硬件驱动层，操作系统内核，分布式中间件，并行计算中间件，应用及服务。 在嵌入式软件开发当中，软件工程师经常要直接和硬件进行交互，但是在高性能计算单元上，由于有富操作系统的存在，这部分工作一般由BSP工程师完成。 BSP（Board Support Package）板级支持包，是介于硬件和操作系统中驱动层程序之间的一层，一般认为它属于操作系统一部分，主要是实现对操作系统的支持，为上层的驱动程序提供访问硬件设备寄存器的函数包，不同的操作系统对应于不同形式的BSP，尽管实现的功能一样，可是写法和接口定义是完全不同的，BSP的编程过程大多数是在某一个成型的BSP模板上进行修改，芯片厂商一般会基于其开发板，提供一个可运行的软件基线，开发厂商基于该基线进行修改。 BSP的调试工作是和硬件强相关的，目前普遍会选择由硬件Tier1做掉这部分工作，由于本身的技术壁垒不高，所以有余力的玩家选择自己做也完全不是什么问题。 很多玩家所谓的做自己的操作系统，其实都只是内核之上的中间件。这部分不是主机厂该做的事情，用QNX、Vxworks、Linux、FreeRTOS等，或者以后的鸿蒙微内核即可。虽然这种不直接面向C端用户的操作系统对应用生态的要求不高，但是对于开发者生态的要求还是挺高的。使用这些操作系统的时候，有几个因素至关重要： POSIX是一个操作系统的接口标准，如果一个操作系统对于POSIX兼容性好，那么开源世界中的很多软件模块是可以复用的。举一个例子，cocos2dx 是一个开源的游戏引擎，支持windows、Linux、Mac等系统，不支持QNX系统，但是由于QNX系统良好的兼容了POSIX，我们只花了很少的功夫就把其移植到了QNX上，虽然cocos2dx依赖了好几十个开源的软件库，但调用的都是标准的POSIX接口，所以也都能非常方便的进行移植。有些网关开发中会使用FreeRTOS，其也有专门的拓展库来支持POSIX调用。 举一个反面的例子，Halide是一个专用的图像处理引擎，其构建是基于LLVM编译器框架的，由于QNX官方支持的编译器是基于GNU GCC的，我曾经尝试过要把Halide移植到QNX，但是由于编译器不支持，迁移过程就碰到了很大的困难。所以系统所支持的编译器框架，也决定了很多最新的开源项目是否能被使用。 传统主机厂，不喜欢开源软件，其中最重要的一个原因，是其技术实力太弱，出了问题自己无法解决，但是新的科技玩家，会更加的拥抱开源软件。 主机厂自己做软件，虽然不用去碰内核，但是必须有几个系统方面的高手，主要是应对系统的稳定性问题，这个对于安全性较高的控制器尤为重要，软件进度上的问题堆人力可以弥补，但涉及到架构、性能、稳定性、安全等，做这部分工作就不是靠堆人力能解决的。 所谓的分布式中间件，就是在实时的RTOS内核上，基于POSIX的API，构建的一个跨平台的操作系统中间件，为上层的应用提供良好的计算、通信的开发框架，其作用类似于Android的Framework，只不过主要是针对实时、高可靠性应用场景的。- Service （独立运行的基础服务节点，作为逻辑处理的后端）
从功能上讲，这类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，但是目前还远远不够完善，特别是在并行计算方面。不只是在车载领域，整个中国的软件行业就没有一家像样的中间件公司，和一些投资机构的朋友也聊到了这个问题，我认为最大原因还是这类产品属于工程产品，客户都更愿意看到一个完整的解决方案，而不是给他提供一个中间件，之前快的节奏让大家都只愿意做来钱快的事情，这些慢活儿也没有成长的土壤。 但是在目前的政治环境之下，这种情况似乎迎来了一丝改变，一些贸易冲突，也让大家意识到了，老老实实打基础还是挺重要的。中国汽车行业最大的问题在于，这些玩家都觉得自己挺牛逼的，谁也不买谁的单，都想自己搞一套，但是在这个事情上，真心不是哪一个能独自搞定的。所以我还是建议，大家能够联合起来做点事情，哪怕是投点钱支持一些创业公司搞开源，也比自己搞要靠谱。就算是一家主机厂发起了一个开源项目，大概率其他的主机厂也不会用，必须以中立的身份来做，才能获得大家共同的认可。 在一个标准的基础软硬件平台之上，各家主机厂可以构建自己的服务和应用体系，这也是各家能够形成差异化的地方。针对不同的应用场景（智驾、座舱、网关、车控等），以及各自差异化的硬件设备，抽象一套属于自己的服务体系，SOA只是实现目的的一种方式，大家可以根据自己的理解去拆解、分层、分类，然后形成一套自己的SDK体系，以支持产品业务的快速迭代。 在此基础上，我也期待有一天，能在各个车厂之间形成统一的接口定义的标准，那样一个应用就能够部署到所有车上，这其实是在从Tier1的角度看问题，Classic AutoSAR就是在这个愿景上产生的，对主机厂来说，只要自己所有车型能够统一，就是一个伟大的成就了。随着自动驾驶与智能座舱的发展，大量的以视觉为主的传感器部署到了车上，产生的数据需要高算力的计算单元来处理，就需要一个并行计算的框架来支撑应用程序的开发与部署。原则上来讲，该框架应该属于上面介绍的分布式计算框架的一部分，主要是这部分内容与传统的应用框架不太一样，所以拿出来单独讲。
目前有各种各样的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，可选方案有多种，也不是非此即彼的问题。 此类专业的问题，没人给出最佳实践，即使是特斯拉也是在不断的摸索当中，解决此类问题，模仿只是一种途径，正向的去思考，去设计，也是一种有效途径。软件定义汽车社区，慢慢已经积累了不少专家，后续将会开展一些技术研讨会，也欢迎各位提供问题与素材。 在软件定义汽车的大潮下，车企都在开始构建自己的软件能力，但是传统的软硬件平台架构已经不能满足需求。很多围绕智驾成立的软件公司，也都只是在单独的域内考虑问题，没有从智能汽车整体数字系统架构的角度考虑问题。 车企缺的不是一个智驾域控的解决方案，缺的是在中央计算EE架构下，整个分布式通信计算系统的软硬件解决方案。而此类的基础框架，靠一家车厂的力量，很难构建，也很难在行业内获得广泛的支持，在当前的政治背景和行业现状下，是有机会联合行业的力量，共同打造一个新的生态系统的。- 提供一个参考的中央计算EE架构，定义计算单元和通信网络之间的拓扑关系。
- 提供一个用于实验及验证的参考硬件平台（包含各计算节点与通信网络），可以与芯片厂商以及硬件Tier1合作，在此平台上，各方可以进行软件原型、通信协议的开发及验证，科研机构也可以依托此平台进行教学。
- 提供一个开源的基础软件平台，各方能够以该软件平台为基础，快速构建自己的软件开发能力，该软件平台包含了服务发现、网络管理、权限管理、运行监控、环网通信、升级、日志、持久化等，完整的车控应用开发框架，提供一种统一的接口描述语言。
- 提供一个开放的服务接口标准，将网络信号和ECU功能抽象化、服务化，提供一个服务分层、分类的参考方案，将标准服务SDK化，提供服务适配层设计，用于屏蔽各方架构不同而导致的实现上的差异。
- 提供计算与通信单元软件的架构及参考实现，让各方能够基于软件平台，快速构建HPC、网关、交换机、Zonal Controller等单元上的软件能力。
- 提供一套完整的开源工具链，用于服务的设计、开发、仿真、测试、代码生成等，帮助各方快速将工具用于自动化的流程中去，打通其与云端CI、SDK服务器等数字化系统的联系。
先期成立一个技术委员会，邀请在一线工作的各方专家，以技术研讨会的形式进行交流，达成几个目的：明确各方需求，在技术路线上能够达成一致，梳理需要攻关的技术课题。 在前期需求和技术路线大致明确的基础之上，社区组建早期的架构设计团队，进行相关的方案设计，招募愿意贡献的专家担任各个领域的技术牵头人，感兴趣的公司或创业团体也可以参与承担部分设计，通过技术研讨会也可以对方案进行讨论。 在方案清晰的前提下，社区组建开发团队，开始构建开源代码，有意愿的创业公司也可以参与进来。 在Beta版本发布之后，社区需要组建一个运营维护团队，评审review相关的PR请求，维护版本的正常演进。
说到开源的软件生态，其实行业里面已经有过几次尝试，像Genivi与AGL都想去构建一个这样的生态，但结果却并不理想。抛开其产品本身技术与体验上的问题，最核心的还是其都只是从娱乐操作系统的角度去解决问题，关于车载系统的复杂性，以及娱乐系统在整个汽车软件系统的位置，前面的系列文章已经做过较多的介绍，在此就不再赘述。 这种现象其实和当前很多做智驾的软件公司的处境比较类似，都尝试从某一个功能域的角度为车厂提供一个方案，但问题是车厂在当前数字化转型过程当中，想要的是一揽子的解决方案，而不是某个局部的功能。另外一个问题就是，想要把一些看起很先进的功能模块塞进老的架构里，就意味着要对原架构做很大改动，所以落地过程困难重重。 很多车厂都拥有一个很宏大的理想，都想做汽车领域的苹果——垂直研发从芯片、操作系统、算法、智能硬件等完整的生态，但现实却是，这个汽车界苹果的位置已经被特斯拉占了，大众也用实际行动告诉大家，软件研发实力，也不是短时间砸钱就能构建起来的，从最开始的瞧不上，到慢慢开始蔓延的焦虑，现实在一步一步继续打着脸。这些传统巨头短时间的确遇到了很多困难，但我相信大众、丰田等，在持续不断的投入之下也会慢慢的构建起这种能力。 传统汽车时代的三大件构成了车厂的技术壁垒，在电动时代，很多人都把其等价为了新的三大件，电池、电机、电控，庆幸可以换道超车了，但行业的趋势却慢慢的告诉大家，逻辑似乎有些变化，好像科技实力成了未来决胜的关键。 在软件定义汽车第4篇，我梳理过国内目前的投入现状，那问题来了，凭国内各家这几百人，且各自为战的游击战法，如何对抗这些已有的科技实力玩家，以及正在砸巨资崛起中的传统巨头？ 好像不能只靠梁静茹，想来想去貌似也只有两条路，要么这些游击队被收编为少数几只正规军，要么联合起来干点啥。 新势力们目前还是挺开心的，因为目前还是跟着大哥特斯拉蚕食燃油车市场的增量阶段，还是燃油和电动之间的对决，等到电动之间开展对决的时候，到时候的竞争点又是什么？ 开源的生态，并不是开源某一款软件就完事儿了，其目的是围绕车载数字化领域，提供完整架构、软件、硬件、工具链、文档、讨论社区等等。 国内行业一个比较有意思的现象是，各个玩家都喜欢去扶持一家自己的公司，很少能看到大家共同来培育一家公司的现象，互联网领域虽然也会站队，但毕竟就这么几个山头，偶尔大家也会联合起来做点事情。 如果是一家商业公司去做，一旦发生站队现象，基本其他玩家就会远离，并且所谓的生态，也不是靠某一个公司能够做成的，需要得到广泛的认可和支持，并且需要足够多的开发者参与，以中立的非盈利性组织去推动开源，应该也最佳方式，开源基金会也有能力去孵化生态上下游的创业公司。
最近和不少组织进行了交流，在目前的背景下，开源社区的方向大家高度认同，其定位就是一个非营利性的中立的开源Foundation，如果对此事感兴趣，也想听到您的反馈。 又是一个思绪乱飞的夜晚，花了7个小时码出了下面这些内容，今天不讲技术，主要谈谈之前的一些经验教训供大家参考。
大家经常会听到车厂要招几千上万人的软件团队，先不看具体的内容，听起来好像软件就是一个劳动密集型的产业，只要堆人就行了。
殊不知，这只是在从一个坑跳进另外一个更深的坑，新势力们已经构建起了部分的软件能力，传统的车厂正在努力追赶，这个行业一片欣欣向荣的景象，但先行者的很多的经验教训是值得大家好好反思的。 前段时间，大家都在谈传统车厂的软件危机，这些都是不具备能力所产生的危机，等到大家都有软件团队了，更多的危机还在酝酿当中，汽车技术的复杂性，进一步让这些危机更加明显。
软件危机是软件工程领域的一个说法，说的就是软件工程中所表现出的各种问题，主要体现为以下几点。
看起来比较抽象，我举几个具体的例子，大家自检一下：- 为什么别人家的软件一个月可以更新好几次，而自家半年过去了，非常努力的敏捷开发而一个版本也发不出来？
- 为什么每个功能域都觉得自己没问题了，集成到一起就问题层出不穷？
- 为什么修好了一个 bug，又冒出来几个其他 bug？
- 为什么开发告诉我这个功能技术方案太复杂，这期来不及，以后再做，然而以后还是来不及？
- 为什么一些功能逻辑只有到了实车上，才发现原先的设计逻辑有问题？
- 为什么第一款车已经做过一遍了，这款新车就适配一下，还需要这么长时间？
- 为什么开发告诉我，自己要维护十几套代码基线，功能不都差不多吗？
无法掌控电子架构，软件架构就是空中楼阁，软件部门经常会和 EE 打交道，特别是在新的软件化浪潮下，双方经常会起冲突。其实静下心来分析，这种冲突是双方认知不同造成的必然结果。
传统的EE一般来自于电气、电气自动化、汽车等相关专业，主要有以下几个重要职责： 在传统的离散架构下，其工作以信号为基础，围绕网络与零部件展开，车上的很多功能往往需要多个 ECU 相互配合，定义功能逻辑、信号交互、管理 ECU 零部件开发是日常的工作重心。 在传统的架构下，其工作模式其实是至下而上的，所有的功能性 ECU 都是产业链上有的，组合起来形成各种产品功能。 而在新架构下，工作模式需要至上而下，底层 ECU 提供的都是原子功能，功能逻辑都是在中央计算单元中实现。所以原本的功能定义和划分职责，现在变成了功能拆解、原子服务定义。 在传统的架构下，如果组建开发团队，很自然的就会按照零部件或者功能域去划分，比如智驾、座舱、网关、BCM、VCU 等，一旦这种组织架构形成，想要推行新的技术架构，就会产生非常大的阻力。
组织架构往往是由分工边界决定的，一旦组织架构确定，就会形成一个利益团体，有句话叫撼动利益，比撼动灵魂还难。 举个例子，在中央计算架构下，中央网关退化为多个区域网关，之前中央网关开发的人去干嘛？把 BCM 和 VCU 的业务功能放到中央计算单元的车控单元之后，这些业务由谁来开发？新的架构要取消这两个 ECU，原来的开发部门会同意？ 从这个维度来看，你就知道为什么在传统车厂内部搞这种底层的数字化架构基本没戏，这不是一个单纯的技术问题。另外，如果出去单独成立新软件公司，如果不能决定 EE 架构的，基本也没戏！ 所有的公司刚开始做的时候，毫无疑问最关注还是产品功能，不管怎样先把产品弄出来再说，所有的资源都是围绕着车型的项目在推动。
等到一个车型项目做完，下一个车型项目又开始了，一旦这个过程启动，任何有点技术风险尝试都会被扼杀在摇篮当中，所以永远只能做渐进式的改变，这就导致，会衍生出很多个软件版本。以后每增加一款车型，就要多维护一条产品线。 在靠硬件差异化拼天下的时代，传统的巨头都是车型平台化设计的高手。一个车型平台，需要投入上百亿的资金进行研发，一家大型的车企，可能同时拥有几十款车型，如果每款车的架构都是不一样的，全部都重新开发，这个成本谁也无法承受。
我想在他们内部也不会有人质疑，为什么要花这么大的成本去开发这样一个车型平台，因为经过了时间的检验，采用平台化设计为他们带来了很多好处： 在传统的汽车上，一个零部件随着整车出厂之后，软件一般不会再进行升级，但在OTA的大背景下，车的生命周期被延长，软件在一定的周期内会进行不断的迭代，如果没有平台化的软件作为支持，产品功能的迭代会产生巨大的工作量，而且迭代速度会非常缓慢。
按照传统车厂的节奏，会频繁的推出新的车型，如果没有平台化的软件作为支撑，光是车型适配的工作就会产生大量的开发成本，更不要谈后续的OTA升级，以后每增加一款车型，就要多维护一条产品线，到了最后，可能不得不去放弃一些销量较低的车型的软件迭代工作，这对于购买那些车的用户来讲公平吗。 在传统的印象中，软件为什么毛利润那么高？很重要的一个原因是软件的可复制性，在复制部署的过程中，其边际成本趋近于零。而软件可复制部署的前提是软硬件的平台化。要在一辆未经良好设计的汽车上去迭代软件，后期本身就会演变成一个灾难。 国内车联网的先行者第一款车发布的时候整个人员规模也就300人左右，后续随着体系内的车型不断变多，导致的适配工作呈现倍数放大，人员规模很快膨胀到近千人，主要的资源力量都被吸引到了车型适配当中去，无形之中也影响到了主线产品的开发节奏，即使是把这部分工作交给外包去做，依然也要付出巨大的人工成本。 为什么会产生如此大的适配工作量呢？可以先给大家介绍一下，软件适配车型具体的工作范围。 车载软件系统，开发出来之后，只要芯片平台不变，操作系统不变，按道理来讲是不需要什么适配工作的。但是但由于传统车厂的一些历史遗留问题，以及产品设计理念的问题，会产生以下三类问题。- 车型平台、车型信号不同，导致信号的适配
新的车型，如果是基于同一个车型平台开发出来，其一般只是信号的值，或者信号的个数发生了变化，但是如果两款车基于完全不同的车型开发出来，基本上信号共用的部分就很少，同样是控制某个功能，信号的名称可能完全不一样，并且一个车型上发一个信号能完成的功能，到了另外一个车型上，可能需要多个信号组合才能完成。这会导致，像网关、TBOX、域控MCU、域控MPU的车辆信号处理的中间件、HMI控制逻辑等模块需要进行软件变更。此类功能，是车载软件开发中联调工作最大的部分，并且还必须是在早期就具备的功能，比如PPV阶段，就要求此类功能ready，而其他大部分功能都可以放到SOP阶段，和其他零部件交互的功能，都是联调中最麻烦的，特别是在早期阶段，工程师需要跑各种现场分析解决问题。
- 屏幕适配
咱们国内的整车的产品人员对智能化的理解是不是太肤浅了，喜欢定义各种规格的屏幕尺寸，多搞几块屏幕，没事儿还横屏改竖屏，竖屏改横屏，似乎谁的屏幕多、屏幕大就更智能似的。殊不知，多一块屏幕或者是改变了屏幕的横竖关系，就要重新定义交互方式，而改变屏幕分辨率，也会导致UI布局上的调整， 这些改变会导致软件上巨大的工作量。
- 车型特殊硬件，增加新的软件模块
传统车厂的车型产品中，喜欢弄一些差异化的硬件，而这些功能往往需要增加新的软件模块才能运行，此类功能倒是比较好处理，因为新增的模块总比改已有的模块要方便，新增只影响一个车型，而改已有的模块会影响其他所有车型。
以上的这些因素都会导致软件的变更，而软件的变更也分为几个层次，软件工程中一般会使用git等工具来管理代码，在软件开发过程中，几十上百个软件工程师会共同完成同一个项目，这里面很重要的概念就是“主线”与“分支”，如果多个车型项目的代码能够复用同一“主线”，意味者他们的代码是同一套，工作量会小很多，但是如果某个车型的软件变更，导致他们无法再用同一套，在软件上就会产生一个新的分支，就像大家平时多个人要共同编辑某个文档，一旦大家的修改产生了分叉，就必须同时维护多个版本。 从软件工程的角度来开，软件开发的一般分为，需求分析、领域建模、架构/概要/详细设计、开发/单元测试、综合测试、编译集成、发布等几个阶段。每增加一个分支，就会导致从开发开始所有流程工作量的增加。 从软件的角度来看，采用一些技术上的设计，可以复用已有的模块分为以下几个层次：- 共用同一分支，一次编译，生成一个软件包，能够在所有车型上运行（就像app能够在所有Android手机上运行）。
- 共用同一分支，多次编译，生成多个软件包，能够在不用车型上运行。
- 部分模块共用同一分支，多次编译，生成多个软件包，能够在不用车型上运行。
- 采用不同分支，多次编译，生成多个软件包，能够在不用车型上运行。
有人也许会问，为啥要搞这么复杂，每个车型都采用不同代码，不是更好管理吗？传统车厂包给Tier1做的时候，也的确是这样，因为那个时代，软件和硬件一样，都是一锤子的买卖，不需要后续还进行什么升级。 今天我们谈论软件定义汽车的前提就是，要通过OTA不断的为车升级新的功能。如果都采用不同的代码版本，意味着软件开发团队的规模是和车型的数量成正比的，越往后面迭代，已有的车型都会变成历史的包袱。很多时候，大家在开始做项目的时候，最关注的还是产品功能的实现度，很少关心软件的架构设计和拓展性，积累到一定的阶段，又不敢轻易的进行重构，而后产生恶性循环，导致开发资源的大量浪费，功能大家都能做，但工程能力的高低往往体现在这些看不见的地方。 构建一套基础的软硬件平台，通过良好的架构设计，在标准的软硬件基础设施上，开发出完备的工具链，以支持车型功能的快速开发与快速迭代，是软件定义汽车的基础。 写了比较多的内容，思路也比较发散，总结下来有以下几点建议：
- 在构建新的数字化架构的过程中，如果牵头人不是像马斯克这种有技术决断力的领导，最好就构建一个强有力的架构团队，从技术层面总领全局，否则靠功能域自己相互协调，只能做点优化，改变不了基础架构。
- 构建的架构团队必须包含定义计算通信架构的职责，靠 EE 和软件架构各自为战，做出来的也是个渐进产品。
- 各功能域的职责在新的技术架构下是会发生变化的，不要试图在原有的组织架构下搞出新的技术架构。
- 产品线开发和平台开发要分开，否则就会面临边开飞机边换引擎的惨痛局面，开发资源永远被现有项目所围困。
- 新平台的开发是一个 EE+硬件+软件的综合体，如果总想拿正式车型项目去推动，会让项目面临很多不可控风险。新平台的正向研发过程中面临很多技术决断，建议成立一只独立团队开展前期研究工作。在一定阶段导入正式量产项目。本质是把 R&D 中的 Research 与 Development 分开，并且将 R 前置。
