GOTC 2023，车企也来搞开源！

“软件定义汽车” 这个概念对于汽车行业的开发者、从业者来说并不陌生。结合一句流传更广的话 ——“软件吞噬世界、开源吞噬软件”，似乎可以推论出开源软件对于当下汽车行业的发展至关重要。

然而开源研发变现难、长期主义的特质撞上车企正面临的短期盈利压力，让许多企业都会怀疑投入开源社区的必要性。尤其是过去一年，造车新势力步履维艰，甚至有的车企出现卖一辆亏一辆的状态。传统车企虽具备更稳固和多维度的盈利能力，但对开源投入也有着更多考量。

另一方面，开源开放的模式优势在市场端的好处也非常明显。

“比如传统软件行业中，一家公司开发了一个软件，并且首先贡献出来，那么市场上和其需求类似的企业中就会有一部分来用这个软件，逐渐可能会形成事实标准。此时，社区的参与方就会是业界标杆。从企业长期利益来看，是能够利益最大化的。”OpenSDV 汽车软件技术联盟，技术与生态负责人滕召智认为，立足行业视角与长期主义视角，开源模式可以更好地解决许多产业基础的共性问题，助力整个产业市场的发展。

OSCHINA 邀请到滕召智，请他聊聊当下汽车软件的发展情况，以及汽车行业独特的开源现状，探索如何将开源的长期主义与汽车这个传统行业更好地结合。

在 2023 年 05 月 27 日 – 28 日GOTC2023 全球开源技术峰会上，滕召智将作为 “软件定义汽车” 分论坛的主持人，深入探讨汽车软件的发展。GOTC 大会官网：https://gotc.oschina.net/

先和大家介绍下您现在在做的工作吧?

滕召智：

目前是在中科院的汽车软件创新中心做操作系统方面的开源组织工作，一些车企、科技企业和中科院软件所一起发起了 OpenSDV 汽车软件技术联盟，旨在为行业的共性需求寻找开源模式的共建方案。

汽车的整个开发生态会比传统互联网公司要复杂一些。我们目前在做的主要工作是解决共性需求 —— 操作系统底座，也就是我们所理解的传统的操作系统内核部分。

汽车标准委员会之前对汽车操作系统做了一个划分，包括车控操作系统和车载操作系统，车控操作系统又分为安全车控操作系统和智能驾驶操作系统。车控操作系统对安全性、实时性、稳定性要求非常高，而车载操作系统更加重视开放性、兼容性。比如车控领域，在车辆的电机控制等一些对实时性和功能安全要求非常高的场景，我们需要 “安全车控操作系统”;在座舱人机交互的部分，需要丰富的应用生态，这就是车载操作系统的领域了，比如 Android、Linux 之上自己做交互界面，应对不同的场景和客户。

因此，我们讨论汽车操作系统，就需要在特定的场景下去聊。面对不同的应用场景，又分为商用车、乘用车等，也因此衍生出来很多广义上的操作系统名词。今天我们的讨论，是按照狭义的操作系统去理解，看它是不是属于底层、内核级别的操作系统。目前我们联盟在做的几个操作系统方向都是内核级别的，也是各个企业提出的共性底层问题。

汽车软件：一部分开源，一部分开放

OSCHINA：开源与开放具体怎么理解?

滕召智：

开源大家都很理解 —— 面向所有人，有兴趣的人都可以进来按照同一个 License，同一个共识在社区中去做贡献，以代码甚至文字的形式共建一个项目。

开放有不同的解读。比如像刚才所说的非常底层的操作系统，需要通过操作系统去驱动和管理各种不同的硬件、处理器、外设，并通过一定的方式提供给应用程序调用。这样一个供应链生态下，如何既能让大家参与共同开发，又保障一些架构上的神秘性，那么，我们就可以通过内源的方式，在特定的 “朋友圈” 形成开发资源的共享，或者采用接口开放的形势，辐射到更大的朋友圈来做共同开发。

开放也可能会走向开源，这对于整个产业来讲，是非常受欢迎的，也是社区 Upstream First 的价值观体现。同时，也减少了企业因为技术债务而与主线代码脱钩的情况。

当然，具体的开源步骤、开源时机，和企业自身对该技术的投入产出预期有一定关系，比如在 6 个月或者 12 个月后，把其中的部分功能开源出来，确保社区主线代码互动的同时保障自身技术在一定时期的领先性。也从一定程度上会促进该企业在技术领先性上的持续快速的迭代。也会出现某一些新的功能和特性，尤其是芯片企业，在开发出来后，首先释放到社区，让更多的用户使用和应用，逐渐形成在行业的事实标准，促进自身企业长期利益的增长。

总的来说，开源是大家基本上都熟悉的模式，开放则是包括有阶段性的开源、分批次的开源，也有对外闭源但体系内做内源的情况。

OSCHINA：车企、科技公司等不同身份的主体在参与共创时，意向程度差别大吗?

滕召智：

开源软件越来越多的成为汽车软件的组件和底座，这是无容置疑的发展趋势，但车企、供应商在整个开源生态的角色，从开源获益者，使用者，参与者，到领导者，各不相同，每一个企业或者机构的角色面对开源生态的态度也会千差万别。

同一个机构或者企业内，也涉及到很多角色、或者很多决策立场和价值观，我们在与企业和机构沟通过程中，也需要根据不同的反馈做出调整，尽可能说服大家能为产业的基础技术共建作出一些贡献。

汽车行业面临颠覆生产模式的问题，生产、研发的协作方式，需要有一个更高效的方式。开源是一个在互联网企业验证过的成功生产模式，但这种模式并不是汽车行业的银弹，不是每个行业的统一解决方案。开源与否只是在某个生产工艺或者是在某个环节，使用开源的生产模式有可能会提高效率，尤其是产业链之间集成的效率。这是我们正在探索的一个路径。

OSCHINA：你们可能现在去做布道的时候会遇到的比较大的难点是什么?

滕召智：

最大的难点是让别人跟你达成共识。汽车的市场虽然很大，但是现在的车企都很卷，很多厂商现在的日子不是特别好过，关注点还是在如何提高产能、如何降低成本、如何稳定供应链上，所以压力非常大，你想让他再去投入短期内不容易看到结果的资源到开源协作里，是非常难的。

但是反过来讲，我们如果说能够跟他讲通一个底层逻辑 —— 产业层面的基础研发不需要你单个企业用全栈的思维去做，而是说如果我们有一个社区版本能够帮你解决最底层的问题，那企业本身就能够更专注地去做产品的优化创新，提升产品竞争力，或者是提升消费者相关的用户体验，增效往往比降本更具效果。这是我们需要去传的 “道”，需要去从产业的角度思考问题。

另外，让车企贡献代码也具有一定的挑战，合规、安全都是一些新的问题。

OSCHINA：放大到整个出行产业中去看，您觉得说开源模式的正、负面影响分别是什么?

滕召智：

就像刚才聊到的一点，开源并不是解决问题的银弹，但是开源确实分为两面性。第一，在不那么了解开源的企业里面，可能会造成使用开源的不合规，反倒产品在应用了开源之后，会惹上后面知识产权的纠纷等等，也会不利于出海，因此，我们也需要让企业合规的应用和使用开源软件或组件。开源的优势也比较明显，比如一家公司开发了一个软件，并且首先贡献出来，那么市场上和我类似的企业中就会有一部分来用这个软件，慢慢可能会形成事实标准。此时，参与贡献越多的就会成为行业领头者。从企业长期利益来看，是能够利益最大化的。但是很多企业没有办法理解开源是一个长期的过程，可能投入了一点点时间就放弃，那开源确实会对原本的商业模式造成冲击，这里面确实是一个比较复杂的问题。

OpenSDV—— 解决行业共性问题

OSCHINA：许多人还不了解 OpenSDV，可以和大家详细介绍下吗?

滕召智：

OpenSDV 是一个面向国际化的、汽车软件的技术联盟。从汽车行业来看，操作系统对应的就是刚刚所说的供应链体系，操作系统对应的像芯片 MCU 这些，这些我们统称叫硬件，那这个硬件的供应链体系其实它就成就了你上层的软件体系。如果是在现在复杂的世界格局下面的话，如果我们不主动去拥抱全球供应链，那可能只会越做越小，因为如果仅限在中国，那么国内的车企、芯片、产业等等不利于汽车产业的发展。我们希望能够通过开源的方式、或者开放的方式去整合一些国际化资源，也能够让海外看到一些中国的技术力量。

从软件所或者从这种科研院所的角度来讲，理论这些东西其实和产业还是很远的，所以就必须要把车企、科技公司、高校、科研机构等等拿在一起，去共同建设。否则的话，就是一家之言，或者是我们所谓的科研的眼界其实是达不到最终落地的目标的。

OpenSDV 目前主要是汽车操作系统相关的工作组，比如操作系统工作组、车云系统工作组。

未来的车肯定不是一个孤立的终端产品，它是一个能够互联的新的计算平台，或者是一个新的数字产品，这里面就涉及到各种各样的架构了。

我们目前也在跟外部合作，主要是软件的合规，为了让中国的汽车或者是源自中国方案的汽车能够顺利出海，顺利销向全世界，那软件的使用开发一定是要合规的。

其实开源软件的使用推广并不是难事情，难点是合规使用，难的是加入开源社区积极贡献。我们现在也在做的事情就是首先去做开源，去影响一些企业的决策者，让他们认识到开源的好处和风险，以及未来应该怎么样去拥抱开源开放。

产业角度来看，开源是一个大规模工程的组织组织方式。很多基础项目其实就应该开源，让大家都能看到代码，遇到难题大家可以一起解决。有跨界开发者进来可能会给开源代码带来突变，就跟基因突变一样，可能会产生新的物种，甚至可能会产生创新的东西。

利用开源的协同办法，还有知识产权的一些机制，也能够诞生更多开发协作方法，比如刚才提到的开放。软件始终是个工具，开源是一种生产模式。就看我们怎么灵活地在汽车行业里去应用?

我们现在主要研究开源模式在汽车行业各个场景中的最佳方案，探索出更好的合作模式，让后来的开源社区、团体去找到比较快捷的拥抱开源的方式。

OSCHINA：刚刚提到的共性问题，有没有具体案例?

滕召智：

比如说操作系统层面，对于某个芯片的支持优化，对于某个新架构的支持……

如果说比亚迪想解决这个问题，长安、长城等等大多数车企也想解决这个问题，那很大可能就是产业的共性问题。如果此时单一企业想去解决，就要聘请非常资深的内核工程师，花费巨大的成本和时间去搭建专业团队。但中国目前符合这种要求的内核工程师是可以数得出来的，也就几百上千人的量级。他们也不可能集中到一家公司去工作，所以就必须要有一个组织方式能够把这些人团结起来，去共同形成一个虚拟、无边界的团队，共同在一个平台上去解决问题 —— 这种组织方式属于大家投入都是最低的，但是效果是最好的。

那么这种组织方式，只有开源或者开放的模式对大家是最公平的，因为代码是公开或者共享的，大家的工作流程也都是公开的，所以各个企业也都可以放心让大家去参与，从共建的基础代码上，获得群体智慧的力量。

OSCHINA：这时就需要中立方，或者说行业联盟才可以做?

滕召智：

是的，如果说是某一家公司去做大家都会有所顾忌。但是放在一个独立的第三方平台上，大家相对来说会很放心，而且这个属于共有知识产权。

我们也希望国家政府能够有更多引领性的支持方案，也希望通过联盟的方式能够让产业的声音够传达上去。如果大家找到共性需求，那是不是国家可以去设计相应的课题，然后大家去共同解决?因为一旦要解决问题，就涉及到成本，这个成本谁来承担?如果是产业共性问题，我们需要尝试说服政府通过课题的形式，投入资源集中解决问题。

但如果只有一家企业或者几家企业在发声，声音不够大或者影响力不够，那么问题其实会被无限制地拖延，在拖延的过程中我们就只能用别人的方案，整个产业就会被别人牵着鼻子走。

软件定义汽车是伪命题吗

OSCHINA：软件可以定义吗，怎么定义?

滕召智：

最开始谈软件定义汽车，是因为有一个词 “软件吞噬世界”。软件定义汽车更像是大家为了更快地传播，才造出的名词。实际上我们在跟一些车企沟通过后发现，其实这个词就跟数字化转型一样具有一定的侵略性。

这两个名词都是站在软件厂商的角度，或者开发者的角度去思考问题。假设我们换位思考一下，程序员其实是不太懂汽车本身，比如机械的运转、控制等，这些其实是一个很复杂的系统，单纯从软件或者从程序员的角度是看不全面的。其间也需要很多翻译过程，需要很多人去给程序员解释该怎么做。从我们国家本身人才培育的积累来看，懂汽车又熟悉软件开发的人非常稀缺，大多数软件开发人员和现有的汽车研发流程和技术要求，本身是存在 GAP 的，开发人员需要有一个翻译去理解软件如何应用在汽车中，而翻译的人如果深入了解这个行业，那么，他的翻译就可以起到利用软件来创新，为汽车制造工艺和汽车产品赋能的目的。

审视软件在数字化过程中的定位，其实只是一个工具，而非教练员。上周我们在一个交流会上，狄安有一个观点：数字化转型这个词应该叫做数字化原生，有很多企业应该是从数字上长出来，然后自己去定义这个软件，而不是用现成的软件去定义自己的企业，这样就本末倒置了。这个观点我比较认同，我们最终用的是软件工具去提升效率，找到创新点，而不是说要因为这个软件去转型，这是不科学的。

所以说回软件定义汽车这个词呢，我的理解是，软件没有办法去定义汽车，软件可以赋能汽车的生产工艺流程更标准化，更具能效，更有可复制性，也让汽车产品的技术解耦，组合灵活，人机交互更便捷，通过应用软件产生无限可能。

我们目前也正在探索是：为什么一定要让车厂参与起来，因为车厂那里才有真正的原始需求。仅靠软件公司或者是软件开发者去思考整个汽车产业，就只是单方面的。所以其实软件定义汽车从媒体使用的角度，我觉得没太大问题，但是从技术层面讲，我们更希望看到的是一个双向奔赴的共创的过程。

OSCHINA：您觉得中国汽车软件整体的市场成熟度大概是处于什么样的阶段?

滕召智：

从汽车软件整体的成熟度来讲，中国在座舱内做的还挺好的，消费者的用户体验挺好。

但是对于开发者就不是那么友好，因为底层的很多操作系统，大多数目前用的都是闭源的。还有很多操作系统，比如 QNX，都是商业的，而且要改一个东西的成本也非常高。代码不透明的话我们也没办法随意去改变供应链，可以用某个器件去替换某个器件，这在很多体系里改动成本都非常大，还涉及到功能安全问题。

如果我们再不去优化自己的生产模式，不去优化软件开发过程，可能会陷入造得越多亏得越多的窘境。

所以在整个汽车软件方面还任重道远。

汽车软件未来的常态：开源与开放并存

OSCHINA：您个人什么时候接触到开源软件的?

滕召智：

2003 年的时候，那时候机缘巧合第一次接触 HP Unix，但那时候遇到问题很难问到人，我们的老师其实也不太懂，所以只能在网上寻找答案。就在 IRC 频道(聊天室)里面去问，不同的频道可以找到不同技术讨论组，来自世界各地不同的讨论组，可以在里面及时地去问世界各地的高手、技术爱好者。或者是在邮件列表里去找遇到的问题等等。那个时候接触了一段时间的 Unix，也就大概认识了开源的这个魅力 —— 有时候你在 IRC 频道里面问问题的时候，会有很多人热心地去帮你解答，也会帮你粘贴各种各样的文档帮你节省更多的时间，因为开源本身就是一个群治的模式，能够让大家非常节省力量、减少浪费、减少重复造轮子的方式，达到认知的目的。这是我觉得，开源模式对我学习模式、学习方式的颠覆。

2004 年的时候算是系统性地开始接触 Debian、Fedora 操作系统，再后来，主要是参与公司项目的时候，因为那时候我所在的公司几乎全用 Linux，那个时候也公司里面也有很多顶尖高手，有 Debian 的 DD，Anthony Fok，他以前应该算华人圈里面贡献比较大的 Debian 的 Developer。还有 Alex lau 等等前辈，学到很多新的知识，参与了一些开源项目，2005 年也经常和大家出没在 Beijing Linux User Group。那时候也是因为参加这些活动，和章文嵩老师，Ubuntu 社区的 freeflying 等等，直接在线下直接沟通，问问题，了解行业内目前正在发展的技术是什么样子。2003 – 2008 那段时间我认为差不多是国内做开源的第一个黄金时期。

OSCHINA：什么时候进入到汽车领域，去做汽车行业的开源工作的?

滕召智：

接触汽车领域操作系统的项目是在 2009 年左右，但是那个时候基本上属于公司的项目，而且参与程度有限，直到 2020 年左右，在开放原子开源基金会做了一些工业领域和汽车领域的国际开源项目分析。包括 Linux 基金会的 AGL 社区，AutoSAR 开放联盟，Modelic 社区。做过一些调研。

后来也是有机会在软件所参与到 OpenSDV 联盟的筹备工作中，逐渐开始深入学习。我们发现，很多国际性汽车软件技术社区，或者像 AutoSAR 这种开放联盟，国际上的一些汽车相关的开源机构，国内企业的参与度，或者说话语权其实是很差的，所以我们也希望国内有一个源自中国基因的开源社区，也能够在国际上发声，所以 OpenSDV 的定位就是建设一个有中国企业高度参与的国际汽车软件技术联盟。

OSCHINA：可以聊聊您和 OpenSDV 接下来的研究方向吗?

滕召智：

我个人可能很大程度上会在操作系统的开发、组织方式上做一些更深入的了解。我们在操作系统有一些优势，可以去做协调组织方面的工作，去探索和发掘一些车企厂商的共性问题，聚焦解决资源整合问题。也可能会探索一些自动化生成、改造开发过程方面的一些研究。

OpenSDV 联盟层面，我们是希望能够面向产业基础的技术底座的部分去做一些攻坚的事情，能够去为产业做一点事情，输出一些参考实现，服务于行业内的基础软件企业，汽车企业以及培养一些面向汽车底层软件的人才。

我昨天跟章文嵩老师聊起来汽车软件的事情，从整体软件行业，汽车软件未来可能会是一个封闭但开放的情况。软件部分可能会分的很细：底层软件、中间件、应用软件等等。底层软件部分可能最适合通过开源的方式去做，当底层基础技术变成行业共建，形成共识的时候，因为兼容互通，应用层面的开放就会变得欣欣向荣，汽车企业会将资源投入到生产模式创新，汽车产品的用户体验、应用场景的创新上，使得整个行业百花齐放。

开源开放肯定是并存的，这可能是汽车软件生态未来的常态。

OpenSDV 也是希望能够去在开源和开放里面去找一个平衡点。另外立足于中国，我们是希望能够去看一看面向下一代的电子电机架构的操作系统长什么样，我们是不是可以在跟跑的同时，去探索一下前面的路是什么样子?

要实现所谓的弯道超车，跟着别人跑是永远达不到的，那么我们得想下一代操作系统应该是什么样，或者我们想象中的电子电气架构的域融合、解耦等这方面未来会是什么样子?我们是不是可以直接从面相新架构的未来操作系统入手，去做一些探索?然后在这个架构上去做一些全球化的技术共享，通过这种方式为整个产业提供解决方案，也能够通过这种方式去应用到全球各地的不同的车厂里面，收集到不同的反馈，能够让这个成为有中国基因的未来事实标准。

滕召智将在 2023 年 05 月 27 日 – 28 日 出席 GOTC2023 全球开源技术峰会，并担任 “软件定义汽车” 分论坛主持人，深入探讨汽车软件的发展，敬请期待!

全球开源技术峰会(Global Open-source Technology Conference)，简称 GOTC，由开放原子开源基金会、 Linux 基金会亚太区、上海浦东软件园和开源中国联合发起的，面向全球开发者的一场盛大开源技术盛宴。 GOTC 2023 将于上海举办为期 2 天的开源行业盛会，将以行业展览、主题发言、特别论坛、分论坛的形式展现，与会者将一起探讨元宇宙、3D 与游戏、eBPF、Web3.0、区块链等热门技术主题，以及开源社区、AIGC、汽车软件、开源商业化、开源教育培训、云原生等热门话题，探讨开源未来，助力开源发展。

大会官网：https://gotc.oschina.net/