黄亮：蔚来在汽车智能化的实践与思考

发布时间：2024-12-28 22:24

2022年11月8日-10日，由中国汽车工业协会主办的第12届中国汽车论坛在上海嘉定举办。本届论坛以“聚力行稳蓄势新程”为主题，共设置“1场闭门峰会+1个大会论坛+16个主题论坛”，以汽车产业的高质量发展为主线，与行业精英一起贯彻新精神，研判新形势，共商新举措。其中，在11月10日上午举办的“主题论坛10：开放、协同，软件定义汽车生态圈的新常态”上，蔚来汽车有限公司高级总监黄亮发表精彩演讲。

谢谢主持人，我是蔚来汽车的黄亮。我在蔚来汽车目前是带领整车软件的交付团队，来交付我们所有蔚来汽车上面的汽车软件。我们蔚来汽车到目前为止在车辆上自研软件的比重非常大，包括自动驾驶、座舱还有很多内部的中台、后台的很多软件都是我们自己自研，这个比例还会继续扩大。

蔚来汽车也是在不断学习和演进过程中，因为业界的变化非常快，我们秉承着用户体验为中心的理念下，我们对于汽车软件的迭代速度也非常快。今天借助这个平台，给大家做一个分享交流，分享一下过去这几年我们学到的经验或者是自己的认识。

到目前为止，至少从我们自己的角度来看，汽车行业智能电动车的软件面临着有一些行业来的挑战，这些挑战可能是外部环境所导致的。简单看一下：

第一，我们现在越来越面临着“以用户体验为核心”的快速迭代交付的场景，大家想一下智能手机或者说金融行业，或者说移动互联网、互联网，大家都经历了这样的过程。现在汽车也处在这样的状态，我们面临的不只是自己的节奏做长周期交付，而是以用户体验为中心的快速体验迭代交付。

第二，存量用户的持续运营带来的持续软硬件的迭代，我们并不是像传统的汽车行业一样，我们丢一辆车，两三年以后基本上这辆车就会换代。实际上现在大家对于智能汽车的认识来看，上面的软件基本上是持续迭代的过程，只要有一天还有用户用这个车，我们就不会放弃对这类用户软件的服务和迭代，甚至硬件也会面临同样的情况。

第三，现在多车型、多产品对于平台的需求，我相信各位也深有体会，传统在汽车行业里面也有机械平台的概念，软件行业里面现在更是一个数字化的平台、软件平台支持多款车，甚至多个市场、多个区域、多个类型用户不同的软件版本，都会存在这样的场景。我们目前汽车电子电气的架构也在向中央化、集中化、分层式的软件架构在演进，这跟分布式的基于域控制器，或者说基于零部件的组合网络的概念非常不一样。后面我们会简单分享一下，这个概念对于我们软件的体系化效率和软件开发是非常重要的基础。

第四，自研比例增大，给自研主机厂带来的人才管理和组织流程上的挑战，以及突破式的基础创新给我们带来研发上的挑战。突破式的创新大家可以认为自动驾驶是突破性的创新，底层操作系统的演进也是突破性的创新，去年很多同行大家都不陌生，我们芯片荒带来的，可能也是属于技术深带来的很大的波动，芯片荒可以找替代芯片，替代芯片需要改软件，后面需要分叉，后面带来一系列的维护的问题。

这样的情况之下，我们觉得要针对这些方面应对挑战，基本上解决这些问题：

1、真正建立以用户体验为中心的快速研发迭代的组织、流程、工具和相应的技术，我们必须快速响应用户的变化频繁去发版本，频繁到什么程度呢？举个例子，去年蔚来汽车，大家可以查公开的数据，小鹏、特斯拉，一年OTA的版本大概是在10个左右，至少在10个左右，有的可能还多一点。大家除一下这个数字，平均每个月会有一个版本推送到用户那里，这个还不包含内部的版本，以及小的车机上APP的版本，这个能力我觉得是蔚来所有的主机厂越来越要具备的能力。

2、持续响应软件的变化和迭代，这就是我说的突破性基础创新和数字化架构不断的演进带来的挑战，这是我们没有办法忽视的，多代际平台、多车型版本同时交互。

大规模团队，自研和供应商混合式研发也是我们要构建的，为什么呢？虽然说我们在目前都集中在云计算资源这一块，实际上供应商的合作必不可少，怎么去更好和供应商合作？也就是说未来在软件方面进行合作？可能要突破之前供应商简单的甲方和乙方的关系，可能要打造更深层次合作的供应链，在软件不同层次上有一个非常深度的融合，我觉得是蔚来的一个趋势。

另外在突破式基础创新之下需要整套完全和研发团队的支持，这些东西都是过往汽车行业的传统。甚至以往比较成功的互联网，包括纯软件行业来讲这些东西都是很大的挑战，因为我们汽车行业又更加复杂一些。

简单给大家分享一下我们大概在未来这几年的一些心得或者是我们学习到的一些点。

首先，我们在蔚来汽车整个的研发思路是一个目标导向的突破性技术研发，而不是一个成熟技术的整合性研发，这背后体现了整个公司研发团队非常大的转变。成熟技术的整合式研发必然是风险管控，必然是瀑布式按节点、时间、质量驱动，不允许出太大偏差这样的东西。突破式的目标导向技术研发，意味着我们在过程当中不断调整自己、适应风险、适应变化，遇到问题解决问题，有突破性研发对用户有价值、有好处的我们就会去试它，只要对成本、效率化有改善的我们也会尝试它。这个过程当中团队的思维方式不是Checken Balance（音）的管控方式，这些都是我们会出现变化的点，控制器、芯片、传感器、算法等等，包括架构、体验。

体验的变化大家套用互联网的概念来看，在整个研发过程中变化非常快，我们一辆车整个生命周期2年也好、3年也好，甚至更长期也好，一开始定义的体验一定不是一年以后、两年以后，那个时候还会是这样的体验，这个过程当中一定会发生变化，我们怎么平衡架构软硬件带来的影响？这是两种态度。第一种我们可能不要去改变，符合用户新的需求，另一种态度是说我们要尽所有的可能满足用户新的更好的体验，这两种方式显然我们采用后一种目标导向的突破性研发。

今天还有一个关键词“敏捷”，我们怎么把敏捷的思想贯穿到研发之中呢？我们团队做过一个调研，如果有熟悉敏捷的同事可以看到，我们左边列的这些点，包括专注化的交付团队，避免一个人在不同的交付线上做场景结环，另外大家是不是做到一起，还是我们分散到各个地方，通过会议、电话来去做。我们是不是跟每个团队具体的技术人员开发测试有沟通，还是每一个接口人谈判，甲方、乙方、上下游，交付组织节奏上大批量交付集成测试，还是小批量的集成？包括我们等到一个车发出去之后接受用户反馈，还是过程中很快接受用户反馈，还有底下自动化测试这些东西，都是过往敏捷测试过程当中积累下来丰富的最佳实践和原则。

越往右对汽车行业也是同样的，我们企业效率一定会得到提升，交付一定会越敏捷。相反越往左越接近于传统的瀑布式按部就班、长周期的交付方式，是非常僵化的。应该说这个公司，整个行业的趋势都是为了向右转移的趋势。

我们也总结了很有意思的一个东西，自己内部叫体系化效率的公式，大家可以讲敏捷的，我们怎么度量敏捷东西的成效呢？我觉得首先一个交付速度，第二用户体验，因为没有用户体验有再高的效率其实是没有用的，团队的氛围我们也很关注，团队氛围背后体现的是团队里面各个小团队之间互相协作的良好的程度。

另外，我们需要在这个过程当中减少浪费、提升质量，也就是减少缺陷。这个过程中减少了我们在软件研发里面关注的研发指标和北极星方向性的指标。

前面我们也谈到一些原则，包括我们的挑战，具体怎么做呢？这里简单跟大家稍微挑几个点讲一下：

1、架构上的演进，大家可能在各种投行报告和研究报告当中发现，我们现在所有的汽车研发架构都在从域控制器向中央集成式转变，大家可能没有从软件的敏捷迭代或者是提高效率角度去看这个问题，它如何对我们的整个软件交互产生如何的影响？这个趋势一旦转型成功，大家可以想象以后汽车的软件研发像安卓手机，因为底下硬件慢慢会越来越集中化、标准化，操作系统会越来越成熟化，隔离硬件的变供，上层的软件越来越趋向于SOA基于服务基础上的APP快速迭代，每个APP就像我们手机上的APP，这个相比以前基于纯嵌入式软硬糅合在一起，左边改了一个控制器会影响周边所有控制器的研发方式显然具备了更敏捷的技术。我觉得新的基础化架构的演进，不光对汽车软件行业，其他方面的这些目标都是非常重要的，实际上对我们敏捷的交付也是非常关键的。

2、在我们这里从过去几年的经验看起来，现在的软件研发模式已经不像以前完全遵循软硬结合的“V模式”的开放模式，“V模式”大家应该都熟悉，“V模式”讲的是要严格管控，所有的软硬件要严格的同步，必须从顶层需求开始，系统架构，软化分软硬，最后集成交付出去，实际这种方式是把两边的迭代速度强行绑在一起。

现在我们采用的是H形的平行结构，软硬件之间有关联、协同，也有耦合，我们大部分的节奏里面让它们并行，我们识别出它们的一些关联点，我们让它们尽可能并行跑，特别是软件，绝不可能在第一辆车发售之前的过程，更重要是SUD之后持续迭代的过程，和硬件的研发流程、整车研发流程一定要解耦。我们必然是采用这样一种模式，也是我们践行的模式，这也是我们软件能够比较灵活本着用户体验为中心去演进非常重要的根本原因。

这里其实也看出来了，我们这里一个整车的流程举例，这个流程各公司都有，没有也会建这个流程。软件里面像下面小的绿色的线段，每一个线段大家可以理解为大的迭代，整车交付过程中第一辆车交付过程中肯定是匹配这辆车整个的交付节奏，什么时候VB，什么时候TD，什么时候SUD，肯定匹配这个节奏一起迭代交付软件的，这是没有问题的，我们也有这样一套流程，并且这套流程在我们这落地了好几年时间，目前是非常成熟的流程。

SUD之后，我们软件还是要不断迭代，这就是非常大的区域点了，我相信过去一段时间来，很多主机厂或者是汽车行业都在讨论的话题，我们如何做好OTA？OTA是更好的能力，OTA可以快速把软件功能做开发、迭代，最后把OTA功能做开发、集成、迭代，最后用OTA把它给释放出去。可以看到整车第一辆车型之后还有第二辆、第三辆，可能还有欧洲或者是其他客群的车，这些车都意味着不同的软件版本，我们软件流程在这个过程当中基于同一个数字化平台不断做小版本的迭代，支持不同车型在不同阶段的软硬交互的。这是非常复杂的过程，以车型数量和软件平台数量做一个层级的话，我们软件交付团队同时处理的软件版本可能有几十个。

这里对软件的交付周期有非常高的要求，我们能做到6个月一个版本还是3个月一个版本，甚至是2周一个版本，这是我们现在在追求的一个方向，也是抛给所有汽车软件从业者的一个难题。

另外要让整个软件迭代流程跑得特别顺利，我们建立了端到端的交付闭环，这是需要非常强的流程支持，过去一年时间内我们打造了这样的闭环，我们可以非常精准、快速从一个用户的反馈形成用户需求，在整个软件流程里面，在很多研发部门和零部件、软硬件协同范围之内，非常精准让所有的需求传递下去，并且及时交上来、集成、充分验证到OTA手里，这样一套机制是我们整个背后迭代运作的核心内容。

说完这些东西我们再回来说一下团队，这个团队如果想要做到非常敏捷的交付，团队是一个组织基础，我们在过去几年之内，简单说从单个平台少有的几辆车到现在至少有两代平台，未来还有先进平台的预研研发工作，以及我们有很多辆车在欧洲已经发过，很多的软件版本。

这个过程怎么让我们既有队伍很好支持这个过程呢？包括实现我们前面说的敏捷的原则性的落地？我们认为非常重要的是建立交付线和职能线双向的协同机制，以前只有职能团队基础上，要么只有能力交付一个平台的车辆，一个平台上面的软件，因为大家都在做一个产品，你是测试的、我是开发的，你是座舱的，我是车身的，我是车联的大家都可以集成在一起，如果有并行并联的时间如何集团内协调资源，如何投入专家保障每一个平台独立的迭代速度，这带来了一个非常大的挑战，所有的企业在这个过程中会经历这样转型的痛苦。你会发现原来职能CUE的头，这些专家们大部分都去搞交付了，根本没有时间来带团队，团队人的建设，后面技术先进的预研和工具的打造全部都落下来了，因为我光搞交付都来不及。

所以我们现在很重要的是说把交付线和职能线有分开的相融的组织结构，交付线去打仗，职能线帮你建设资源，中长期重要不紧急的问题，同时把工具和技术打造好。

这个结构其实是非常复杂的，也是实现敏捷迭代的基础。

最终说一点，我们有了这个团队，有的前面的原则，我觉得蔚来文化也是非常独特的，蔚来文化我们前面说目标驱动的突破性技术研发，我们组织上也是以工作目的为驱动的目标驱动工作方法。如果是右边的话，我们都是靠KPI，必须在这个点交什么东西，质量、缺陷一定不能高于什么，所有人都会开始互相防备，上下游之间会互相推托，组织效率一定不会能够提上来满足我们刚刚说的交付状态。更不要强调一些所谓的一号位、所谓一些领导的判断和这样一个管控，我们每个人都是目标导向，每个人都可以提出自己的观点，基本上以解决问题为出发，如果是解决方案技术性的留给专家去做。

我们目标是形成团队真正基于我们的目标，基于问题解决、效率协作的一个组织结构，这确实是挺难的事情，但是我觉得这也是蔚来整个工作文化氛围里面比较独特的点，有了这个东西支持我们前面的流程、技术能够得以实现的最根本的原因。

最后总结一下，我们软件体系化效率的六大原则，也是在整个交付过程总结下来，或者可以称为敏捷交付的六大原则。

1、灵活敏捷的跨智能交付团队。

2、稳定专业的职能专家团队，一个是后方，一个是前方。

3、小粒度的频繁集成验证、持续交付。

4、松散耦合的分层软件架构。

5、可靠的自动化工具支持。

6、快速反馈和调整。

这些东西听起来和敏捷都非常接近，我们做的工作是把业界所有包括敏捷在内的实践和原则融合到我们企业里面来，为了我们这个用户的体验不断提升和体系化效率的提升，来打造属于我们自己的体系流程、工具的一套组合，谢谢大家。

网址：黄亮：蔚来在汽车智能化的实践与思考 https://mxgxt.com/news/view/560240

上一篇: 全面深入对比蔚来、小鹏、理想、零

下一篇: 蔚来车主有了个新称号，叫蔚忠贤