赵福全对话曹斌（下）：破解汽车持续进化困境

凤凰网汽车访谈 智能汽车若想名副其实，必须可以持续进化。OTA为重要手段之一。当车企都谈OTA的时候，两面性显现出来了。一面是升级的便利和更高产品力，另一面是自己“挖坑”和巨量的投入，甚至会引起混乱麻烦。

跨越时间与多款车型的OTA等升级，到底有多难？表象背后依旧是造车的底层逻辑问题。除了硬件标准化和软硬解耦，如何构建可脱离特定车型的软件架构？而更远的“硬件可插拔”如何实现？

延续（上中）篇谈到的汽车硬件标准化、软件森林生态和定制化困境话题，凤凰网汽车《赵福全研究院》第69期（下），继续深入“汽车技术生态创新”，赵福全院长对话东软睿驰汽车技术（上海）有限公司的总经理曹斌，深度解析汽车软件升级的困境和出路。

摘要：

用户共创成鸡肋？

如果开放式创新的规模和效果不足以显著提升车辆能力与用户体验，那么让用户参与创新就可能会变成一种鸡肋。前期必须建立支持的架构和平台。但若收益不足，后续是极其困难的。由于车辆的高安全性，留给外部开发者的空间并不是很大。

大鱼的游戏

小公司的生存空间已经变得很小了。也就是说，当手机系统变得更智能，开放式的创新空间被压缩了。这是智能产品发展到一定阶段后必然会出现的结果。汽车生态更大的发展路径是，从一开始就由一些重量级的参与者，推出高复杂性、高可靠性和高质量的人机交互软件。

强者恒强

软件是强者恒强的游戏，需要持续优化，最终才能越做越好。如果一家车企能够集中力量开发一组软件，然后在未来的几款甚至几十款产品中坚持应用，不断完善和优化，那这组软件的竞争力必将越来越强，其优势最终一定会显现出来。

OTA的复杂度

怎样以一套软件系统匹配全部车型？以哪款车型为基准来实施软件系统的OTA升级？是不是只能在部分车型上升级，而另一部分无法升级呢？老实说，目前还没有哪家整车企业能够清晰解答这些问题，

指数级难度

当前硬件的架构和标准化程度还不足以支撑软件的不断升级，无法做到始终都能保持强兼容性。如果车企要对未来几十款车型同步进行升级，其难度将呈指数级上升。

OTA要求硬件标准化

为了降低OTA升级的复杂度，正如前面我们讲到的，企业必须努力实现硬件的标准化，否则当需要维护的软件版本过多时，车企在资源和精力上也无法应付，结果很可能是一款车只做了几轮OTA之后就不再更新了。

中间层很关键

关键在于中间层的软件能力，具体来说，就是要构建可脱离特定车型的SOA架构，并形成可支撑软件长期迭代更新的核心团队。要迭代升级的这部分软件是基于软件中间层、基础层直到硬件层的抽象概念来进行开发的，才能跨越十年以及几十款车型。

可插拔现实吗？

可以通过插拔进行更换，这无疑会给用户带来额外的吸引力。但是这样做也会带来很高的成本，而且实施起来或许要比在新车型上直接使用最新型号的芯片等硬件更加困难。未来可插拔式的硬件升级必须是严格限定的，即提前明确几种可允许的替换方式。

与时间解耦

所谓整车平台化软件，就是与部门无关，与功能解耦，而且也与时间解耦，与具体车型解耦。过去我们总是说软件要适配硬件，今后更应强调硬件适配软件。

可淘汰

未来汽车产品将越来越带有快销品的属性。也就是说，汽车企业可以更期待用户由于芯片等硬件无法支持最新的软件系统，而选择淘汰旧车、购买新车。

长期主义

如果车企在一代产品上着重开发这个功能，到下一代产品又去开发那个功能，总是“做一个、丢一个”；又或者刚把一代产品开发好，下一代产品却又换了另一个团队，毫无延续性和积累性，是不可能把软件真正做好的。

以下为对话实录（下）

切勿让用户参与汽车产品创新变成鸡肋

赵福全：现在有的车企已经在尝试，把汽车上的某些部件或功能开放，让用户参与设计，自行选择配置，即所谓的C2B模式；还有的车企提出，可以让用户开发某些应用软件，然后上传给整车企业进行验证和批准，而一旦获得批准就可以将该功能向所有用户开放。这就不只是在产品开发阶段按照消费者的需求由企业进行定制化设计了，而是给用户留了一个开放的端口，让其直接参与汽车产品的开发过程，而且还可以在车企的背书下，向所有用户推广。我认为，这是一个很大的进步。

不过按照曹总刚才讲的，从长远来看，这种模式似乎是不必要的。按您的推断，既然汽车的智能程度已经进化到用户提出任何需求都能予以快速判断和满足，哪里还需要再让用户参与软件开发呢？不知道您怎样看待车企的上述尝试？

曹斌：这些尝试本身无疑是有益的。总的来看，在汽车智能化升级的方向上主要有两种创新模式。一种是自主式创新，采用这种模式的企业通常实力很强或者正面临极其复杂的技术问题；另一种是开放式创新，即企业引入外部力量一起参与创新，以弥补自身创新能力的不足。

开放式创新一旦走通了，企业的创新能力就会变得非常强大。不过开放式创新是非常困难的，需要良好的土壤。一方面，在这种模式背后，企业需要有架构平台以及相关能力的有力支撑；另一方面，外部力量尤其是用户，要有深度参与创新的足够空间和积极性。

对于汽车产品而言，由于车辆的高安全与高可靠性属性，其实留给外部开发者的空间并不是很大，或者说是比较小的。在此情况下，如果开放式创新的规模和效果不足以显著提升车辆能力与用户体验，那么让用户参与创新就可能会变成一种鸡肋。因为车企为了向用户开放可以参与产品开发的接口，必须建立起能够提供相应支持的架构和平台。假如收益不足，后续再想改变这种架构和平台是极其困难的。所以，我建议车企在初期一定要系统思考、慎重决策，以免由于方向和模式上的选择错误给企业未来发展带来严重制约。

赵福全：这就引出了一个新问题，在您看来，开放式的创新生态对于汽车产业来说到底有多大价值呢？一方面，当企业自身的创新能力强到足以满足消费者的绝大部分需求时，那么对于剩下的一小部分需求，即所谓的长尾部分，企业就无需在意了，很可能这些消费者也不属于企业的目标用户群体。如果为了争取这些消费者，不得不在产品上做很多预留，甚至影响到架构平台、开发接口以及配套能力等的布局，恐怕就不值得了。这样说起来，开放式创新生态的意义似乎并没有那么大？

不过另一方面，车企自身有足够的能力判断和满足所有消费者的各种不同需求，甚至有能力挖掘、创造出一些消费者没有提出或想到的需求，这也许将是永远无法达到的理想状态。而在汽车还没有智能到如此高的程度时，车企为什么不能通过开放式的创新生态，让用户都可以参与产品开发，从而帮助自身提升满足用户需求的创新能力呢？从这个意义上讲，开放式的创新生态不仅仅是必要的，而且是至关重要的。对此您怎么看？

曹斌：我认为，这与生态的发展阶段有很大关系。比如说现在我们有在手机上开发某种应用的需要和动力吗？恐怕绝大部分人都没有，因为手机生态已经非常丰富了，足以满足大家的需求。事实上，与几年前相比，当前大家手机上的应用已经发生了很大的变化。5年前很多人手机上的应用都不一样，各有各的选择和喜好；但是今天大家手机上的应用趋同性极强，像社交软件几乎全都是微信，还有短视频、娱乐及游戏平台等应用软件，也都是主流的那几款。

不难发现，这些被广泛应用的软件的提供者几乎都是大公司。相应的，小公司的生存空间已经变得很小了。也就是说，当手机系统变得更智能，可以提供更高级的功能和更卓越的体验时，个人消费者的参与度反而下降了，或者说开放式的创新空间被压缩了。我觉得，这是智能产品发展到一定阶段后必然会出现的结果。

那么，未来汽车创新生态会如何发展演进呢？一种可能的路径是，先经过各种开发者百花齐放的阶段，然后一些应用的开发者会成长为某个领域内的巨头，相应的，其他的小开发者会逐渐退出，最终形成普遍趋同的局面。而我个人认为，可能性更大的发展路径是，从一开始就由一些重量级的参与者，推出高复杂性、高可靠性和高质量的人机交互软件，并很快在各个主要领域占据主导地位。

我的判断主要有两点依据：一是汽车产品具有高价值属性，消费者购买汽车要比购买手机的花费高得多，这确保了各巨头企业参与汽车创新的积极性。二是汽车产品极度复杂，开发和使用周期长，安全性、可靠性和耐久性等要求高，小公司或个人恐怕没有足够的能力和资源开发好标准如此高的汽车软件。

当然，在汽车生态的发展过程中，也有可能会出现以上两条路径的中间状态。不过，我认为其概率是很小的。而且即使出现这种情况，也是不稳定的，后续肯定会产生新的变化。所以目前来看，在汽车领域面向个人或小团队的开放式创新确实处于比较困难的状态。前面谈到汽车生态是森林式生态，也是指这个生态的主要参与者是整车企业以及软硬件供应商，这些企业都是有一定规模的“树木”，而不是体量微小的“野草”。

赵福全：实际上，这正是当前汽车企业的领军人们最为纠结的问题之一。手机虽然可以作为重要参照，但毕竟与汽车有着很大的不同。目前手机应用生态经过多年的发展已经相对成熟，有比较清晰的开发模式和生态格局。但是对于汽车企业来说，过分与手机比较或者模仿手机，参考手机生态的路径来发展汽车生态，可能并不是最佳的选择。我们常说，在战略上首先要明确“我是谁”。这个“我”一定是汽车，而不是手机。所以，汽车行业应该学习和借鉴手机行业的一些做法，但不能“忘我”的学习和借鉴，那样恐怕最终会迷失方向。

谈到这里，我想梳理一下之前交流中得出的几个核心观点。

第一点，未来硬件一定要标准化和抽象化，这样软件才能发挥更大的作用。要实现这一点，需要行业尽早达成广泛共识，同时也需要相关参与方积极进行探索和实践。哪怕先从几家整车和供应商企业构成一个小合作群开始，也应该努力朝着这一方向前进，因为这事关企业未来的核心竞争力。反之，如果行业不能达成共识，企业逡巡不前，那整个行业的进步都将因此受阻。

第二点，操作系统至关重要。当前大家对操作系统的范畴有各种各样的不同理解，对此我认为，企业一定要避免把操作系统的概念泛化。同时，企业可以考虑自行开发操作系统，但必须清楚，如果自建的操作系统没有生态支撑，那将是毫无意义的。

具体来说，操作系统最终一定是共享的，而非独有的。单一企业很难独自支撑操作系统，因为如果只是一家企业在用这个操作系统，那每个模块都必须与供应商逐一进行单独沟通，不仅任务繁杂、工作量巨大，而且代价高昂、难以持续。以这样的方式来做操作系统，即使一时效果不错，最后也会由于无法得到产业生态内各种资源的有效支撑而陷入困境。

正因如此，操作系统一定要向整个产业生态开放。整车企业可以根据自身的目标、重点和竞争战略，决定主攻操作系统的某一部分。例如，可以选择只做座舱操作系统；也可以组建3000人的软件开发团队，尝试做操作系统中的更多部分。但是无论企业的软件团队有多大、能力有多强，都仍然需要拥抱整个产业生态。如果只是把自己体系内的供应商拉进来一起做操作系统，而没有把操作系统推向更多的使用者和参与方，是很难构建起产业大生态的，未来也很难有持续生长和发展的空间。

第三点，手机开发者生态是草原式的，而汽车开发者生态是森林式的。汽车不同于手机，对于安全性的要求要高得多。即使能够向用户开放的应用，也要高度关注用户参与这部分开发所带来的潜在风险。有一些应用软件，整车企业与其向用户开放，远不如多投入一些，由自己或者优秀的供应商来负责。也就是说，对于用户可能想到的、期待的功能和服务，汽车企业或许应该把其中的99%都先预留并尽力做好；剩余且受控的部分，再交给用户去做选择或二次开发。即给用户的留白越少越好。

在这个过程中，车企要真正形成让汽车产品更理解人的能力，即只要用户有相关需求，车企就能够做到。当然具体要不要做，还需要根据安全风险和投入产出比进行衡量。而不是说由于车企没有能力为用户开发所需的功能，就干脆开放相应的端口，让用户自己来开发，这种开放逻辑是不正确的。更何况让用户广泛参与产品开发，将使后台系统加倍复杂，并带来潜在的功能安全隐患。

这实际上体现出两种不同的产品开发思路及方式。我们不妨做个比喻：一种是让消费者挑选菜品甚至自行做菜，以解决众口难调的问题；另一种则是把消费者可能点到的99%的菜品都预先备好，剩下的1%要么忽略，要么在质量受控的前提下少量留给个别消费者自己动手来做，以满足其个性化需求。

未来车企可以为发烧友留下定制开发的空间

赵福全：曹总，您判断汽车生态不是草原式的开放大生态，而是森林式的相对集中的生态。这样有实力的软件供应商将会拥有更多的商业机会，可以根据汽车产品的特点，把自己擅长的工作做足，从而让汽车变得更聪明、更能读懂用户和满足用户，而不是让用户自己动手来开发想要的功能。您认为这样才更符合汽车产业的特殊性。

就目前来说，情况可能确实如此。不过今后等到车企有了足够的能力和把握时，是不是应该向用户开放一部分接口呢？毕竟用户中还是有骨灰级车迷和发烧友存在的，比如现在就有不少改装车的发烧友。那么，您觉得未来汽车创新生态中，会不会有个人消费者参与产品开发的空间？

曹斌：我想，所有具备情感属性的商品最终都会有一部分属于发烧友的空间，未来汽车企业也应该给发烧友们留下一定的定制开发空间。不过这部分消费需求一定是小众的、非主流的，而且明显不同于大众消费者。因此，车企可以为汽车发烧友们提供深度定制或二次开发的空间，甚至可以开放自动驾驶等道路测试，但需要对用户有明确的选择和限定。我认为，未来或许会诞生纯粹为发烧友而设立的汽车品牌和产品，这是完全有可能的。因为当汽车行业发展到一定阶段后，一定会有企业深耕不同的细分市场。而喜欢自行设计和定制开发汽车的发烧友群体，无疑是一个颇具潜力的细分市场。

赵福全：关于我与曹总交流的以上话题，相信大家都有自己的观点，各自的理解也有不同之处，这非常正常。不过曹总作为懂汽车的软件专家，基于多年来在汽车软件领域耕耘的经验，为我们分享的观点和见解，无疑会给大家带来很多思考和启发。这也正是我邀请曹总来参加本栏目的目的——我们就是要开诚布公、知无不言地深入探讨当前汽车软件创新发展中的一系列核心问题，从而为整个行业以及各类相关企业提供有益的参考和指引。当前汽车产业变革不断深化，恰是各类企业八仙过海、各显其能的关键时期。此时企业能否前瞻地制定正确的发展战略，要比以往任何时候都更为关键。这无疑增加了我们今天这场对话的价值。

汽车软件分层：基础层、中间层和上层应用软件

赵福全：下面我们来讨论一些汽车软件的细节问题，您认为汽车软件到底应该分为几个层次？它们之间是什么关系？各层级的软件应该由哪类企业主导完成？对于整车企业而言，究竟应该着重抓住哪部分软件？

曹斌：汽车软件的分层在最近一两年里已经越来越清晰了。那就是软件主要分为三个层级，即基础层部分、中间层即中间件部分和上层应用部分。其中，中间层包括实时系统和非实时系统。另外，从功能角度还可以有自动驾驶、信息娱乐等不同系统的划分。不同系统以及不同车型之间有很大的区别，不过都可以分解为上述三个层级，这一点业内已经形成了共识。

总体而言，我们可以把软件比作一棵树苗，这棵树苗的成长需要三个必备因素：阳光、土壤和水。其中，阳光是促进软件成长的外在动力。软件的“阳光”就是其应用部分，应用越多越广，树苗就越健壮，生命力就越强。而土壤和水则关乎软件成长的内在动力。软件的“土壤和水”包括企业的适宜组织与开发团队等，也包括企业掌握的相关技术诀窍（Know-how）。

具体来说，首先，基础层软件属于通用组件，主要就是底层操作系统。过去一些车企对此有过自行开发的想法，但是现在车企已经越来越清楚，这部分组件是通用化的，应该在很多车企的很多车型中被广泛应用才行，并且用得越广泛越好。

实际上，无论是底层操作系统还是中间件，都是为上层应用提供支持的，目的就是让上层应用软件的开发变得更加方便，为此要把底层软件之下的硬件设备、拓扑结构等充分打通。我认为，对于基础层软件和中间件来说，还是应该由一些独立的供应商来开发。这既是因为独立供应商的专业能力更强，也是因为独立供应商更容易与多家车企达成合作，从而扩大这部分软件应用的范围和场景。

其次，软件的逐步完善一定是需求导向、应用引领的。软件总会有这样或那样的一些缺陷和不足，需要在实际使用过程中不断迭代和优化。不少软件在发展过程中都经历过“添坑”的阶段，即不得不逐个填补原有的漏洞。也唯有如此，软件才能最终走向完善，并形成自身的先进性。从这个角度来看，软件接触的应用越多，其完善的速度就会越快。

此前有些企业的操作系统或中间件在市场上得到了认可，但也有不少企业所做的类似软件未能发展起来。我觉得，这主要不是企业之间人才或技术存在差距的问题。真正的原因在于，成功企业的软件接触到了很多应用，有机会将这些应用不断沉淀并有效组合起来，使自身的生命力越来越强，客户的信赖度越来越高；反过来，这又让其接触到更多的应用，从而得以持续优化，最终越做越好。所以我认为，软件是一个强者恒强的领域。

最后，对于汽车软件行业未来的发展，我有以下三点判断和建议：第一，基础层软件包括操作系统内核、硬件驱动软件以及特定硬件的专有软件等，要与下面的芯片等硬件连接和交互，这部分软件应由软件供应商来完成。第二，中间件会越来越成熟，最终形成一套被广泛应用的标准化软件，并与相应的管理工具和适配服务等组合在一起。第三，整车企业应着力打造上层应用。上层应用软件的类型众多，有些应用体量很大，如自动驾驶和智能驾舱系统；也有些应用是针对特定硬件或总成的，比如空调控制等。今后车企应选择关键的系统性应用和受众面广的“小”应用进行有针对性的开发。

在此我想再次强调，软件的发展是与组织紧密耦合的，因此必须高度重视团队的传承；同时唯有在持续迭代和演进的过程中被不断打磨，软件才能越做越好、成长壮大。如果一家车企能够集中力量开发一组软件，然后在未来的几款甚至几十款产品中坚持应用，不断完善和优化，那这组软件的竞争力必将越来越强，其优势最终一定会显现出来。反之，如果车企在一代产品上着重开发这个功能，到下一代产品又去开发那个功能，总是“做一个、丢一个”；又或者刚把一代产品开发好，下一代产品却又换了另一个团队，毫无延续性和积累性，这种打法是不可能把软件真正做好的。

把硬件充分抽象化是有效实现“软硬平衡”的前提

赵福全：前面谈到，在“软件定义汽车”的时代，软件与硬件之间的关系将比过去复杂得多。对此，我几年前曾经特别提出过软硬关系的四段论：即未来在汽车产品的开发过程中，首先要“软硬分离”，将软件和硬件基于各自的规律、按照不同的方式进行开发；继而要“软硬组合”，确保软件和硬件在物理上可以无缝连接、灵活组合；进而要“软硬融合”，使软件和硬件有效匹配、融为一体，在整体上呈现出最佳效果，这也是新汽车追求的最高境界；最后还要“软硬平衡”，主要是衡量产品的性价比，以确定适宜的硬件预留策略。

“软硬融合”的前提是不变的硬件能够为变化的软件提供有效支撑，而任何产品都必须考虑成本，这就涉及到当前业界普遍关注的又一个焦点问题——面对不断升级的软件，硬件究竟应该如何预留？如果硬件预留不足，后续将无法发挥应有的效能，难以支持软件的升级；反之，如果硬件预留过多，且不说未必能够做到，即使有性能足够前瞻的硬件，恐怕企业也承受不了其高昂的成本。更进一步说，当硬件不敷使用或趋于老化之际，软件还要不要升级？又该如何升级呢？曹总，您怎么看这个问题？

曹斌：现在一些汽车企业已经基于软件实现OTA（空中下载）功能了。这意味着车企可以对已售出的产品随时进行软件升级，以提升车辆性能，这也是当前行业发展的一大趋势。不过在OTA升级方面，目前还有很多可以完善的空间以及很多尚待解决的难题。

实际上，OTA升级的原理并不复杂，但实际运营起来却非常困难。假设有一家车企在10年间销售了几十款产品，这样在市场上既有该企业10年前售出的车型，也有其刚刚发布的车型。这家车企要怎样以一套软件系统匹配全部这些车型呢？又应该以哪款车型为基准来实施软件系统的OTA升级呢？企业最新的软件系统是不是只能在部分车型上升级，而另一部分车型则无法升级呢？老实说，目前还没有哪家整车企业能够清晰解答这些问题，而这正是企业继续探索和实践的动力所在。

赵福全：这也是我们这个对话栏目的价值所在——我们提出关键问题、进行充分探讨，并在思想碰撞中尝试给出答案，供行业参考。回到刚才的问题，这确实也是我近期思考最多的问题之一。假设企业推出了一款车型，之后不断进行OTA升级，但是几年之后，由于硬件的落后和老化，软件系统将无法再升级。而此时用户还不想更换新车，企业就会陷入进退维谷的尴尬境地：如果不再对产品进行升级，就意味着这款车型在后续的生命周期内都无法实现所谓的“常用常新、越用越好”了，这将引发用户的不满；而如果要继续升级，车企又该如何处理不足以支持软件的硬件呢？

也许车企将不得不在老化的硬件上强制升级最新版本的软件系统，但这样一来，车辆的功能和性能到底会变好还是变坏呢？又会不会产生安全风险？我感觉恐怕用车体验没有明显变化就是一个不错的结果了，很可能是体验反而下降，就像旧手机运行新系统时会变慢一样；而且新软件与老硬件的不匹配，还可能会导致行驶安全方面出现问题。说起来，能力强大的软件控制能力弱小的硬件时，究竟将是怎样一种情况呢？不知道曹总有何高见？

曹斌：赵院长，这个问题我是这样看的。首先当前硬件的架构和标准化程度还不足以支撑软件的不断升级，无法做到始终都能保持强兼容性。例如很多车企今年发布的车型与去年发布的车型相比，在硬件架构上本身就是不同的，包括软件可以调用的硬件种类和数量是不一样的，芯片的计算能力和特性也是不一样的。在这种情况下，如果车企要对未来几十款车型同步进行升级，其难度将呈指数级上升。这相当于每开发一个新功能，都要逐一适配于几十款车型，每款车都必须重新匹配和验证一遍。

尽管如此，OTA升级却是今后车企必须具备的能力。为了降低OTA升级的复杂度，正如前面我们讲到的，企业必须努力实现硬件的标准化，包括域控制器内芯片特性的定义也要标准化；同时必须搭建面向未来、可延续的硬件架构平台，这样才能为软件的迭代升级提供基础保证。如果硬件这一层都没做好，那软件的升级只会越来越难，甚至刚过一两年就难以为继了。因为如果软件不断进步而硬件停步不前，企业就不得不迁就老硬件而维护过时的软件版本，这样不仅无法体现出新软件的先进性，而且还要付出高昂的成本代价。即使不考虑成本，当需要维护的软件版本过多时，车企在资源和精力上也无法应付，结果很可能是一款车只做了几轮OTA、修补了少量BUG（漏洞），之后就不再更新了。我认为这是未来车企必须面对的重要问题，其本质是在新汽车的换代升级过程中，如何有效平衡成本与收益。

通过“软件先行”扫清迭代升级的最大障碍

赵福全：曹总，对于这个问题，当前业界有没有比较可行的解决方案？毕竟企业今天的布局直接影响明天的结果。如果现在有整车企业的领导问您，当几年之后汽车硬件已经老化或者落后，无法支撑新的软件系统时，要如何才能使自己的产品“老树开新花”呢？对此，您会怎样回答？

曹斌：这就是我们提出“软件先行”模式的根本原因。具体来说，首先要确定软件系统中后续需要不断优化的核心部分到底是什么。然后要将这个核心部分完全抽象出来，从中间件即SOA这一层开始，到基础层操作系统内核，再到硬件架构，逐层完成抽象化。最终的目标是，即使硬件在不同时期和不同车型中可能会有很大差异，但逐级上升到SOA服务层时，硬件架构的定义仍然是一致的，这样上层应用软件进行任何迭代更新都不会遇到障碍。也就是说，要迭代升级的这部分软件是基于软件中间层、基础层直到硬件层的抽象概念来进行开发的，这样才能跨越十年时间以及几十款车型而不会出现问题。

对于整车企业来说，这是现在就需要深入思考的事情。而东软睿驰向车企提供SOA和中间件服务，就是为了解决这一问题。我们希望在必须先确定软件底层逻辑并开发标准软件这一点上，广大车企能够达成共识。也就是说，在产品开发之前就要先行开发相关软件，而且所开发的软件系统不仅要针对现有车型，还要考虑适配于未来车型。

过去我们总是说软件要适配硬件，今后更应强调硬件适配软件。未来在定义好的边界内，无论是底层硬件架构，还是具体的每个硬件，例如域控制器内来自不同厂商的芯片，其差异性都应该在软件各层中被彻底抽象化。尚未做到这种抽象化，是当前在整车架构层面上存在的最大问题，应该优先予以解决。如果整车企业现在就认识到这一点，开始系统谋划和前瞻布局，着手进行产品开发“软件先行”的组织搭建和模式建立，那么将来就有机会彻底扫清软件迭代更新的最大障碍，使自身产品拥有长久的活力和持续的竞争力。此外，基于这种理念，企业还可以进一步思考，软件的性能如果不够，应该如何解决？承载资源的空间如果不足，又该怎么办？

当然，这将是一个渐进的过程。事实上，如果非要让软件系统为10年前投产的车型进行OTA升级，这恐怕永远都是一个难题，即使在当前成熟的手机领域里也并没有实现。未来汽车产品会有越来越高的算力需求，也会有越来越多的功能及算法，比如神经网络等各种AI算法，现有的硬件算力肯定不足以应对。当软件在某款车的硬件上“跑不动”的时候，用户就会意识到这款车已经无法进行升级了，这个型号的产品已经过时了。在此情况下，假如用户选择继续使用这款产品，可能也不太会抱怨车企不再提供升级服务了。

而整车企业则应在产品序列中提供一套相对固定的、便于消费者理解的表达方法，包括车型型号及其对应的软件版本。例如，随着软件的进化，车企将不断发布新车型和新软件。此时，企业就可以通过产品型号和软件版本号向用户说明：五年之内某款车型的软件可以持续升级，五年之后主要软件就不能再升级了；或者五代以内的车型可以继续升级，五代以外的车型就不再支持升级了。如果能够提前告知，相信用户也是可以理解的。

软件能否升级不应影响硬件寿命及其正常使用

赵福全：一般来说，传统汽车所有零部件的设计寿命都是一致的。比如某款车型的设计寿命是15年，那么工程师会把发动机、变速器、车身、底盘等的设计寿命都定为15年。不过在“软件定义汽车”的时代，就像您刚才谈到的，未来软件迭代升级很可能做不到覆盖5年之前的车型。如此一来会不会出现这样的问题——本来设计寿命是15年的车型，但由于软件无法持续升级，导致车辆功能受限，甚至不能完成制动、转向等基本操作，从而使汽车的使用寿命远远短于预期呢？

例如一辆用了几年的汽车，其制动系统的硬件还是完好的，但制动控制软件却无法再升级了，甚至可能都无法正常启动和运行了，这样岂不是会造成安全隐患，最终使整车不得不被提前淘汰吗？即使车辆的基本使用没有问题，不过硬件在不断老化，又不能通过软件进行有针对性的调整，这样汽车的性能势必趋于衰退，又如何体现智能汽车“常用常新、越用越好”的优势呢？如果这台所谓“聪明”的汽车，用起来却是个“短命鬼”，或者用上一段时间之后就不再“聪明”了，那用户还会青睐和信任智能汽车吗？曹总，您认为这个问题应该怎样解决？

曹斌：首先，涉及车辆基本功能的硬件，无论汽车如何智能化，都不能降低其可靠性和耐久性要求。比如底盘结构件、车身框架、动力系统以及制动、转向机构等，也包括车门、车窗等功能硬件，其寿命至少要和传统汽车一样，甚至要做到更长。在这方面，我认为软件能否更新不应该影响硬件的寿命和正常使用。换句话说，即使软件不更新，也必须保证硬件能用、够用。

另一方面，车企也要努力延长软件升级所能覆盖的时间跨度，尽可能让新车型上推出的新特性，也能在老车型上通过软件OTA实现，从而为老用户提供同样的体验。在很大程度上，车企为老车型进行OTA升级的能力强弱，将直接决定用户的品牌忠实度。因为用户在购车之后，通常不会很快换车；而在用车的全过程中，用户肯定希望能更多地享受到软件升级带来的新特性和新体验。如果车企能够做到这一点，那么不仅有助于提升用户的美誉度和忠诚度，而且对于智能化品牌形象的建立，也会有极强的促进效果。

赵福全：对于传统汽车来说，用户换车的动力通常来自于配置和造型，因为新车型会有更好的硬件和更新的造型风格。而未来车企售出的新车型与老车型相比，很可能在硬件上并无太大差别，甚至完全一样，只需通过软件的不断升级就能让用户获得更好的体验。这就让汽车具有了“老树开新花”的能力，从而将会彻底改变汽车产业的商业逻辑。

曹斌：是的，未来大部分汽车硬件都可以保持不变，没必要频繁更换。同时正如我们刚才谈到的，一些事关软件运行效果的关键硬件，如芯片等关键处理器件，今后将受到消费者越来越多的关注。例如中央计算单元、自动驾驶芯片以及智能驾舱芯片等的算力，对车辆性能的影响很大，所以消费者对这些芯片的关注度肯定会比以前高得多，甚至有些消费者可能会由于某款车型上搭载了先进的芯片而选择购买。显然，像这样的汽车硬件，是需要不断升级的。

事实上，这些事关车辆功能、性能的关键硬件，将成为未来汽车产品先进与否的关键评价指标之一。如果这些硬件难以满足用户需要，又不能单独进行更换，用户或许就会淘汰旧车而换购新车，这也是一种新的消费动力。总体而言，我认为未来汽车消费将越来越像当前的手机消费。我们知道，处理器的换代升级和内存的扩大增容，会让大家产生换手机的欲望；而今后汽车产品很可能也是如此。这也表明在消费不断升级的趋势下，未来汽车消费者会有越来越多非常精细的关注点。

可插拔硬件模式挑战巨大，需严格限定替换空间

赵福全：曹总，可插拨的硬件也是当前汽车行业交流较多的话题之一。在您看来，未来哪些汽车硬件可以设计成插拔式的？这些可插拔的硬件要如何支撑软件的持续升级呢？

我认为，硬件能够实现可插拔，对于软件供应商来说将是重大利好。试想如果汽车都是由不可插拔的硬件构成的，即使这些硬件的寿命很长，但由于后续软件无法持续升级，或者说，芯片等关键硬件的性能无法支撑算力需求更高的软件，结果必将导致失去了软件赋能的汽车产品逐渐落后，重新成为不智能的传统汽车，在使用效果上与现在的汽车并没有本质差别。反之，如果硬件可以灵活地插拔更换，就可以在更长的时间里支持软件的升级，从而让企业在软件方面的投入产生更大的价值。与此同时，未来也许硬件的寿命也没必要设计得太长，这将有利于降低产品的成本。曹总，您怎么看这个问题？

曹斌：对于未来汽车硬件是不是可插拔、可更换，应该说，目前业界正在讨论这样的可能性。我个人将其归入某种细分市场，例如某款车型的自动驾驶控制器、智能座舱控制器或者中央计算单元中的核心处理器和存储部件等，可以通过插拔进行更换，这无疑会给用户带来额外的吸引力。但是这样做也会带来很高的成本，而且实施起来或许要比在新车型上直接使用最新型号的芯片等硬件更加困难。

因为设计开发一款在未来很多年内能够不断更换关键硬件的车型，必须保证不会出现任何安全问题，不仅开发难度极大，而且开发成本和组件成本也不容忽视。我想，在一些细分市场上可能会有采用这类技术的空间，例如在某些高端或者高使用寿命的车型上。

实际上，我觉得未来汽车产品将越来越带有快销品的属性。也就是说，汽车企业可以更期待用户由于芯片等硬件无法支持最新的软件系统，而选择淘汰旧车、购买新车。这在成熟的快销品市场是很常见的，就像现在的智能手机一样。由此，关键硬件的进步将成为汽车产品更新换代的重要动力之一，我认为这是未来汽车产业发展进程中一定会出现的情况。

至于选择继续使用旧车的用户，也不用担心硬件老化的问题，汽车的基本功能和性能还是有保障的。因为汽车企业一定会坚守产品的品质关，提供安全可靠的车辆一直是汽车行业的底线。

当然，车企也要努力让新软件能够在老车型上得到更多更久的应用，这会显著提升用户对该汽车品牌及产品的认可度和满意度。而企业实现这一目标的关键在于中间层的软件能力，具体来说，就是要构建可脱离特定车型的SOA架构，并形成可支撑软件长期迭代更新的核心团队。

赵福全：尽管目前业内对于可插拔硬件的讨论很多，不过曹总认为，这种模式实际上有很多困难。那么，能否请您具体分析一下，为什么说硬件可插拔的模式面临着巨大的挑战，甚至不亚于全新开发一款产品呢？

曹斌：通常汽车产品的开发和测试都遵循“V字模型”，即从开始设计到最终定型要先经历从整车到系统、再到零部件的逐级指标分解，再经历从零部件到系统、再到整车的逐级测试验证。整个过程是一体化的，每个层级对匹配度和可靠性都有很高的要求。如果没有走完全部流程，就无法充分确保整车的安全性，或者说，车辆行为的确定性就会下降。

对于可插拔的硬件来说，在开发过程中也必须遵循“V字模型”，以充分验证替换硬件后的情况。理论上每个可插拔的硬件都需要完成完整的验证，再加上多个可插拔硬件之间存在不同的组合，必须评估可能出现的各种状况，其工作量之大、工作难度之高也就可想而知了。此外，还需要额外设置冗余，以防万一新旧硬件组合后出现兼容性问题。上述这些事情都要在产品开发之初，就全面系统地考虑进来。

更进一步来说，还有一个必须解决的难题：对于传统汽车产品，其软件只需基于现有硬件开发即可。而对于硬件可插拔替换的汽车产品，必须保证后续更换了新硬件之后，软件仍然能够可靠运行。但是新硬件或许现在都还没有面世，又如何基于新硬件开发软件呢？这其实才是最难的地方。也就是说，以前设计一款新车，只需要考虑当前使用了哪些硬件；而未来还需要考虑后续会替换成哪些硬件，而用于替换的新硬件究竟会是什么样子，根本无从知晓。

赵福全：我觉得这里面有两种情况：一种是功能性的硬件，比如制动片，使用一段时间后会逐渐老化，这时候就要换成新的。这种硬件的更换并不需要额外的验证，事实上现有汽车产品也存在这种替换。另一种情况是控制器等关键硬件的可插拔式替换，这才是我们今天要讨论的。这部分支撑智能化的硬件，在老化或者落后之后，如果不设法更换为新一代的硬件，汽车的智能化能力就无从保障。从这个意义上讲，即便面临再多的困难，恐怕车企也应该去尝试。

曹斌：其实我们所说的是一样的，我们谈的可插拔硬件都不是指制动片这类传统硬件，而是指芯片这类事关智能化的硬件。传统硬件在老化后进行更换属于正常维护，换上来的新硬件与旧硬件完全一样，只不过是以旧换新而已。然而芯片等硬件并非如此，是要替换为性能不同的真正意义上的新硬件。

通常我们谈及芯片不会讲老化了，而是讲处理能力不足了，也就是不再能很好地支撑新软件运行了，所以才产生了更换新一代芯片的诉求。进行这种更换需要满足两个前提条件：一是诞生了性能更优越的新一代硬件，这一点不会有问题；二是可以把旧硬件拔下来，然后把新硬件或其模组方便、可靠地插入到整个硬件架构中，即实现所谓的“可插拔”。但是新一代硬件会是什么规格和性能，企业当前并不知道，因此想要提前进行合理的预留是非常困难的。

那么，企业究竟应该如何构建能支持可插拔硬件的整车架构呢？我想，只能基于对相关硬件比如芯片未来发展的预测来进行策划和预留。老实说，要把芯片的发展进程，特别是各种具体细节都提前想清楚是很不容易的，更不用说还需要提前考虑各个层级的验证环节。这种模式的难度很可能超乎想象。

所以我认为，未来可插拔式的硬件升级必须是严格限定的，即提前明确几种可允许的替换方式。然后车企只针对这几种变化，进行逐级拆解，明确各项指标及其要求，同时确定如何进行验证。此外，还要充分评估允许这些变化所带来的成本增量。唯有如此，可插拔硬件才能有真正落地的可能性。

需要指出的是，在这个过程中，成本的增加是不可避免的。因为一旦将相关硬件设定为可插拔式，必然涉及到周边很多与之适配的机械、电子部件以及软件系统。这些机械、电子部件和软件系统都必须基于可插拔硬件带来的潜在变化，更改设计指标，并进行相应的开发和验证，这势必增加产品的成本。

车企应建立跨时间、跨车型、独立的核心软件团队

赵福全：接下来，我们谈谈未来汽车产品的开发模式会有哪些变化。此前，汽车产品开发模式相对简单，就是搭积木式的集成模式，很多模块或系统都由供应商负责开发，之后整车企业再把这些模块或系统拿过来，集成到一起。而未来的产品开发恐怕要复杂得多，因为整车企业不仅要集成硬件，还要集成软件；同时和以往不同的是，车企还必须把架构规划和集成工作的重点转换到软件上。那么您认为，整车和供应商企业为了适应未来“软件定义汽车”的新局面，应该在汽车产品开发方面做哪些根本性的调整呢？

前面讲到，几十年来汽车行业一直采用的都是V字型的开发流程。而当前一些企业已经提出了软硬分离、敏捷开发等新的开发理念和方式；同时，由于软硬融合的复杂性，仅仅按照传统“1+1=2”式的简单集成逻辑，对物理接口进行设计及验证，已经远远不能满足需求了。显然，企业亟需在组织架构、开发流程及管理模式等方面，进行全方位的深度创新。

当前不少企业在这方面都有很多探索和实践，特别是车企也在尝试借鉴ICT行业的产品开发经验。例如华为一直力推的所谓IPD（集成式产品开发）模式，即企业自行定义、开发、集成并验证产品；又如软件行业应用较多的敏捷开发等。此外，在产业生态化的发展大势下，汽车生态的参与者越来越多，关系也越来越复杂。因此企业在创新产品开发模式时，不仅需要实施内部变革，还需要在外部建立分工明确、协作紧密的新型商业模式。曹总，在这些领域，您有什么心得可以和大家分享？

曹斌：过去整车企业开发新车，比较成熟的做法是选定供应商分头开发各个零部件，再由车企进行集成，最终打造出一款整车。所以，传统车企中的部门大都对应着不同的总成或部件，如底盘、车身、发动机、电子电气等部门。现在由于出现了自动驾驶方面的需求，有些车企又设立了自动驾驶以及自动泊车等部门。

在此我分享一个有趣的经历，东软睿驰在推广行泊一体的域控制器时曾经遇到过这样的问题：我们的行泊一体域控制器是将行车和泊车功能集成在一起的，由一套软件解决所有的问题，这也体现出更高的智能化程度。然而一些整车企业有行车和泊车两个部门，每个部门都只负责自己的那部分工作，结果我们都不知道应该和哪个部门对接才好了。可见，现在车企真的有必要进行组织机构调整，谋求建立分工更合理、灵活性更强的组织模式。

在我看来，为了开发智能汽车，整车企业首先需要建立独立的软件团队，这应该是面向企业整体需求的软件团队，而非以往面向部件的功能式部门。这个软件团队并不局限于产品开发的时间节点，也不只是针对某个具体车型的开发，而是负责开发企业当前以及未来多款车型的核心的整车平台化软件。所谓整车平台化软件，就是与部门无关，与功能解耦，而且也与时间解耦，与具体车型解耦，能够有效支撑不同时间点上市的不同车型的核心软件系统。这对于车企的软件驾驭能力以及整车架构的规划能力，都是非常大的考验。

在这方面，东软睿驰可以作为车企的伙伴和参谋，和车企一起研究未来软件的发力点，参与车型特别是软件架构的规划。而软件架构需要通过中间层软件来实现，包括SOA架构和中间件等。这些软件中既有通用化的，也有个性化的。今后整车企业在建立面向未来的软件架构、开发能力及核心组织时，肯定会依托中间层软件提出越来越多的要求，并且这些要求是有历史延续性的。所以，东软睿驰现在一方面为车企提供符合AUTOSAR（汽车开放系统架构）标准的基础软件，包括AP（自适应平台）和CP（经典平台）软件；另一方面，也在努力为企业的个性化需求和可持续发展提供支持。

我认为，车企与中间件的供应商或者说合作伙伴一起长时间合作才是最佳选择。至少不能开发完一款车型后，下一款车型就更换为另一家供应商，这样在开发前一款车型软件时所积累的经验就全都浪费了。也就是说，在软件方面车企必须改变每做一款新车型都重新确定供应商的做法。对于开发中间件的供应商来说，需要与整车企业的软件团队共同合作，持续开发可用于若干款车型的中间件；而对于整车企业来说，也需要选择具备优秀架构规划能力和软件开发能力的值得信赖的供应商，谋求建立长期合作的伙伴关系。

而这正是东软睿驰追求的目标，我们一直希望能够与很多整车企业在这种层面上展开合作，帮助车企搭建核心软件团队，共同探讨长期发展方案，包括如何设计软件架构，如何确保软件架构的可延展性等；并与车企一起推动跨车型、跨部件的软硬件解耦，构建面向抽象化硬件的新型软件开发体系。所以我们才倡导“软件先行”的开发模式，建议整车企业在内部建立独立的软件开发团队。总之，东软睿驰致力于成为能够与车企携手前行、同步进化的战略合作伙伴。

在这个过程中，我们会为车企提供通用、可靠的基础组件，而随着更多车企与东软睿驰合作，这些车企就能获得被广泛应用的标准化的基础组件。同时我们也可以提供个性化组件，帮助相关车企基于自身的需要，精准打造产品的“灵魂”。所谓产品的“灵魂”，可能是某个功能级的组件，也可能是某个系统级或者整车级纵向整合的组件。无论是哪种情况，都需要在软件架构特别是中间层上预留出足够的空间，让整车企业能够在这个空间内进行持续的迭代优化与个性化创新。而东软睿驰就是要帮助车企把这些工作做好，也因此我们把自己扮演的角色定义为“伴生式”伙伴。

目前，我们正在和很多车企开展深入合作，帮助车企开发中间件、搭建软件架构以及构建软件开发环境、提供软件开发方法，支持车企完成跨时间、跨车型、跨控制域的软件接口定义，从而使整个软件系统可以持续迭代、不断优化。我认为，无论对于软件能力的形成，还是对于创新生态的搭建，上述这些基础工作都是必不可少的。

软件供应商要帮助车企在通用架构的基础上打造差异性

赵福全：当前，整车企业原本基于硬件的或者说功能性的部门组织仍旧存在。而在“软件定义汽车”的时代，从软件打通硬件功能的目标出发，继续沿用之前的理念和组织就不合适了。因此，车企必须改变原来的离散化状态，先把自己的各个部门打通，否则就无法形成合力。

在车企打破原有组织、构建全新体系的过程中，东软睿驰这样的软件公司可以提供很大的助力。事实上，整车企业要打造面向未来的竞争优势和差异化的品牌特色，目前并没有标准范式可供参考，唯有一边摸索、一边前进。而在摸索前进的道路上，我认为，车企非常需要有意愿、也有能力共同实践的“伴生式”合作伙伴。

由此也衍生出最后一个问题，如果东软睿驰为很多整车企业做了同样的事情，那最后会不会导致这些企业的产品出现同质化呢？

曹斌：一方面，在汽车产品上有些部件和功能本来就应该通用，比如基础的通讯组件，包括跨域或跨服务的定位、访问以及信息安全服务等。对于绝大多数车型来说，这些基础部件并不需要差异化，反而必须通用化；同时还要求能够保持长时间的稳定性和可靠性，这样才能发挥其应有的作用。否则，车辆就会出现问题。

另一方面，所有车企都需要做出自身产品的差异性。不过这种差异性的实现并不需要改变共性的基础组件，而是需要企业在软件架构的预留空间中，基于事先定义好的接口和边界，来完成一系列独特的软件设计。这其中必然涉及个性化和通用化软件的交集，所以，车企需要与开发通用化软件的公司合作，以保证使自己开发的个性化软件可以顺利地与通用化软件组合起来。

当然，可能也会有车企为了实现更彻底的差异性，希望把底层通用化的基础组件也由自己来做。这也是一种选择，但是我个人认为没有必要。原因主要有两点：一是这种“通吃”策略的投入产出太低了，这相当于为了实现产品的差异性，把大部分通用化软件又重新做了一遍。二是这种策略的难度太大了。以东软睿驰为例，我们的主要业务就是开发软件，之前已经与十几家车企、上百家供应商合作过，这些年一路走来，经历过很多“陷阱”，也验证过很多复杂的场景，我们的经验肯定要比一家车企多得多。即便如此，我们现在仍然觉得开发汽车软件是一项挑战巨大的工作。相比之下，要让经验有限、主业也不在通用化软件上的整车企业，仅靠自己的力量来解决种种难题，输出效果优良、可靠性高的软件，其难度之大可想而知。

所以我认为，整车企业必须在通用架构的基础上打造产品的差异性；同时应该与提供通用化软件的合作伙伴深度绑定，在这个伙伴的帮助下，打造差异性的软件。这两点都非常重要。当然，在差异性的具体选择上，各家车企在横向宽度和纵向深度上肯定会有所不同，因此并不存在同质化的风险。

东软睿驰在为车企提供通用化基础软件的同时，还可以输出架构师，而且是成建制的架构师团队，以帮助车企分析和确定架构设计方案、基础软件接口以及预留开发空间等。在此基础上，我们还能以非常高效的方式，协助车企完成个性化软件与通用化软件的集成工作。

赵福全：也就是说，东软睿驰不仅具有开发共性软件的能力，而且具有支持车企开发个性化软件的能力；既可以帮助车企在具体的关键点上实现突破，以解决眼前的产品竞争力问题，还可以输出架构师，协助车企搭建顶层架构，以解决长期的持久竞争力问题。这意味着当整车企业要借助合作伙伴的力量，弥补自身软件能力的欠缺时，像东软睿驰这样的公司应该是比较合适的选择。

时间过得很快，我们已经谈了三个多小时。今天围绕“软件定义汽车”的一系列关键问题，我和曹总进行了非常深入的交流，其中既涉及到当前汽车产品开发中尚存争议的敏感话题，也涉及到汽车产业未来发展的方向判断。下面我把主要观点简要梳理提炼一下。

第一，无论是“软件定义汽车”，还是“数据定义汽车”，又或者是“芯片设计汽车”，并无本质区别。其实这些说法可以说都是正确的，只不过出发点有所不同罢了。

我们知道，最终购买产品的是消费者，而提供产品的是整车企业。因此车企需要基于自身的品牌定位，找到合适的消费群体并进行精准画像。同时，用户在使用汽车的过程中会产生数据，这些数据反馈到整车企业，会进一步提升车企精准定义消费群体和满足用户需求的能力。而数据的产生、传输、分析及应用，无不需要软件，尤其是软件算法对数据处理能力有很大的影响。此外，芯片算力与算法的结合将决定车企对数据的利用和挖潜能力，并在很大程度上决定着未来汽车产品的能力上限。所以，对于智能汽车产品来说，数据、软件以及芯片都是最大限度满足用户需求的关键要素。

第二，在“软件定义汽车”的大背景下，硬件依然重要，不过随着本轮产业重构的不断深化，硬件最终将会走向标准化、抽象化。而硬件的标准化和抽象化将为软件提供发挥作用的更大空间和更多可能性。也就是说，虽然未来软件将占据主导地位，但这并不意味着可以抛开硬件；同时，硬件必须进行相应的转变，以支持“软件定义汽车”的真正实现。

第三，从软件角度来看，汽车操作系统非常重要。对此企业必须明白，离开了生态系统的支撑，操作系统将成为无本之木。当然，面对产业生态化发展的大趋势，各类企业可以站在不同的角度来开发操作系统，并由此选择参与未来竞争的不同分工以及所需的关键能力。不过总体而言，对于共性、基础的通用化软件，整车企业不宜投入过多。毕竟汽车本来就是一个集大成的产业，而当“软件定义汽车”不断深入发展之际，车企不仅需要集成硬件，还需要集成软件，其资源和能力将面临比以往更大的挑战。所以，未来企业更要坚持“有所为、有所不为”，以集中力量打造支撑品牌内涵和产品特色的核心竞争力。

第四，对于软件定义下的汽车产品开发，搭建好架构平台至关重要，因此架构师的作用日益凸显。正如曹总强调的，整车企业当前先要想清楚未来自己的核心竞争力究竟是什么？为此应该规划和建设怎样的架构平台？而不是直接深入到一些细节工作中。与此同时，对于整车企业来说，优秀的产品经理比以往任何时候都更加重要。因为今后产品经理需要基于对未来产业发展大势、市场需求、用户体验以及产品开发模式创新等的深度理解，推动架构师等共同搭建适宜的整车架构平台。而在整车架构平台的建立过程中，产品经理还需要考虑一系列关键问题，例如车企应该选择哪些核心突破点？必须自行完成哪些工作？需要集成哪些外部资源？以及在芯片、各类软件以及核心算法等方面，应该分别与哪些供应商展开合作？等等。

第五，展望未来，技术创新生态的搭建至关重要。不过，汽车开发者生态并不意味着要让所有消费者都直接参与汽车产品开发。事实上，虽然开放式创新能给企业带来前所未有的机遇，但这种模式也将带来前所未有的挑战，毕竟汽车产品有着严苛的功能安全要求。向个人消费者开放某种端口，让他们能够自行设计软件来参与汽车产品开发，无疑可以更好地满足用户需求、增强企业粘性，不过同时也将产生巨大的安全风险，而且车企在架构预留和验证批准方面也要付出不菲的代价。

而曹总又从另一个角度指出，智能汽车的“聪明”应该体现在能够更懂用户，从而更精准地识别和满足用户的需求，并让用户更方便地享受到更好的服务和体验。如果智能汽车必须“麻烦”用户去定制软件，才能满足其个性化需求，那这台车还谈不上“聪明”！当然，对于少量的汽车发烧友，为其开放定制汽车软件的空间是可能的，也是必要的，这会成为一个有潜力的细分市场。但是如果要把这种模式全面推开，曹总认为是弊大于利。同时，整车企业要努力集成更多的优质资源，进行尽可能多的预开发，以便让用户获得最大化的选择空间。

第六，汽车软件人才需求后续将发生变化。当前，行业亟需既懂车又懂软件的人才，这也是近期产业出现“人才荒”的主要原因之一。不过随着硬件走向标准化、抽象化，未来软件人才只需了解硬件的抽象接口定义即可，不再需要掌握汽车很多专业领域的原理和知识，因为届时标准化的硬件可以直接被软件灵活调用。当然，企业的领军人和架构师始终需要具备横跨软硬件两大领域的知识体系。此外，他们还需要了解市场需求的变化，理解产品进化的趋势。例如如何为未来软件的升级做好硬件预留，就非常考验领军人和架构师的战略眼光和前瞻判断力——如果硬件预留过多，将造成成本激增；而如果硬件预留过少，又会影响软件后续的迭代升级，两者都会损伤产品的核心竞争力。

最后我想强调的是，“软件定义汽车”的时代才刚刚开始，还有太多的话题需要探讨，也有太多的问题需要解决。这是企业的挑战所在，更是企业的机遇所在。

在此，感谢曹总和我们分享了这么多真知灼见。祝愿东软睿驰在曹总的带领下能够发展得更好。同时，也期待在更多“东软睿驰”们的帮助下，汽车产品能够早日成为更懂我们的贴心伙伴。谢谢曹总！

曹斌：谢谢赵院长！谢谢各位网友！