软件定义汽车(第八集)构建开源软件生态系统.docVIP

软件定义汽车(第八集)构建开源软件生态系统 1 开源的内容 提供一个参考的中央计算EE架构，定义计算单元和通信网络之间的拓扑关系。 提供一个用于实验及验证的参考硬件平台（包含各计算节点与通信网络），可以与芯片厂商以及硬件Tier1合作，在此平台上，各方可以进行软件原型、通信协议的开发及验证，科研机构也可以依托此平台进行教学。 提供一个开源的基础软件平台，各方能够以该软件平台为基础，快速构建自己的软件开发能力，该软件平台包含了服务发现、网络管理、权限管理、运行监控、环网通信、升级、日志、持久化等，完整的车控应用开发框架，提供一种统一的接口描述语言。 提供一个开放的服务接口标准，将网络信号和ECU功能抽象化、服务化，提供一个服务分层、分类的参考方案，将标准服务SDK化，提供服务适配层设计，用于屏蔽各方架构不同而导致的实现上的差异。 提供计算与通信单元软件的架构及参考实现，让各方能够基于软件平台，快速构建HPC、网关、交换机、Zonal Controller等单元上的软件能力。 提供一套完整的开源工具链，用于服务的设计、开发、仿真、测试、代码生成等，帮助各方快速将工具用于自动化的流程中去，打通其与云端CI、SDK服务器等数字化系统的联系。 2 初步运作方式 先期成立一个技术委员会，邀请在一线工作的各方专家，以技术研讨会的形式进行交流，达成几个目的：明确各方需求，在技术路线上能够达成一致，梳理需要攻关的技术课题。 在前期需求和技术路线大致明确的基础之上，社区组建早期的架构设计团队，进行相关的方案设计，招募愿意贡献的专家担任各个领域的技术牵头人，感兴趣的公司或创业团体也可以参与承担部分设计，通过技术研讨会也可以对方案进行讨论。 在方案清晰的前提下，社区组建开发团队，开始构建开源代码，有意愿的创业公司也可以参与进来。 在Beta版本发布之后，社区需要组建一个运营维护团队，评审review相关的PR请求，维护版本的正常演进。 3 关键要素 设计方案需要得到广泛认可，能够满足各方需求 得有人先站出来贡献第一个版本 需要有稳定可靠的维护团队 需要有正反馈的贡献机制 需要有配套的硬件原型平台 4 背景杂谈 说到开源的软件生态，其实行业里面已经有过几次尝试，像Genivi与AGL都想去构建一个这样的生态，但结果却并不理想。抛开其产品本身技术与体验上的问题，最核心的还是其都只是从娱乐操作系统的角度去解决问题，关于车载系统的复杂性，以及娱乐系统在整个汽车软件系统的位置，前面的系列文章已经做过较多的介绍，在此就不再赘述。 这种现象其实和当前很多做智驾的软件公司的处境比较类似，都尝试从某一个功能域的角度为车厂提供一个方案，但问题是车厂在当前数字化转型过程当中，想要的是一揽子的解决方案，而不是某个局部的功能。另外一个问题就是，想要把一些看起很先进的功能模块塞进老的架构里，就意味着要对原架构做很大改动，所以落地过程困难重重。 很多车厂都拥有一个很宏大的理想，都想做汽车领域的苹果——垂直研发从芯片、操作系统、算法、智能硬件等完整的生态，但现实却是，这个汽车界苹果的位置已经被特斯拉占了，大众也用实际行动告诉大家，软件研发实力，也不是短时间砸钱就能构建起来的，从最开始的瞧不上，到慢慢开始蔓延的焦虑，现实在一步一步继续打着脸。这些传统巨头短时间的确遇到了很多困难，但我相信大众、丰田等，在持续不断的投入之下也会慢慢的构建起这种能力。 传统汽车时代的三大件构成了车厂的技术壁垒，在电动时代，很多人都把其等价为了新的三大件，电池、电机、电控，庆幸可以换道超车了，但行业的趋势却慢慢的告诉大家，逻辑似乎有些变化，好像科技实力成了未来决胜的关键。 在《软件定义汽车（第四集）：谁是最后玩家？》文章中，我梳理过国内目前的投入现状，那问题来了，凭国内各家这几百人，且各自为战的游击战法，如何对抗这些已有的科技实力玩家，以及正在砸巨资崛起中的传统巨头？ 好像不能只靠梁静茹，想来想去貌似也只有两条路，要么这些游击队被收编为少数几只正规军，要么联合起来干点啥。 新势力们目前还是挺开心的，因为目前还是跟着大哥特斯拉蚕食燃油车市场的增量阶段，还是燃油和电动之间的对决，等到电动之间开展对决的时候，到时候的竞争点又是什么？ 开源的生态，并不是开源某一款软件就完事儿了，其目的是围绕车载数字化领域，提供完整架构、软件、硬件、工具链、文档、讨论社区等等。 国内行业一个比较有意思的现象是，各个玩家都喜欢去扶持一家自己的公司，很少能看到大家共同来培育一家公司的现象，互联网领域虽然也会站队，但毕竟就这么几个山头，偶尔大家也会联合起来做点事情。 如果是一家商业公司去做，一旦发生站队现象，基本其他玩家就会远离，并且所谓的生态，也不是靠某一个公司能够做成的，需要得到广泛的认可和支持，并且需要足够多的开发者参与，以中立的非