1、软件定义汽车背景
在过去的几年中，智能手机和计算机，其标准化硬件在现有技术水平下正逐渐接近物理极限，这推动了其行业逐步从由硬件升级发展主导产品创新，转向由软件开发和迭代去推动硬件设计的更新和升级。

诚然，不同于硬件相对标准化的智能手机和计算机行业，汽车产业有着其特殊性，不论是硬件的标准化程度，还是车辆的技术特点差异，都使汽车产业尚未具备客观条件以完全复刻智能手机和计算机行业规律，但伴随硬件标准化的推进和技术差异化的减小，汽车产业也或将经历相似的过程。
无论是出于客观因素，例如受限于生产工艺水平或材料物理特性使得硬件设计达到了顶峰、硬件性能也接近物理极限，还是源于主观因素，消费者对于应用软件带去的创新体验越来越敏锐和强劲的需求，都在推动汽车产业诉诸于软件技术来谋求变革和发展，使硬件技术上附加上更多软件的价值和烙印。
在这一背景下，“软件定义汽车”的说法开始在汽车产业内盛行起来。特斯拉被认为是目前这一趋势最典型的实践者，从面向消费者可见的OTA服务、自动驾驶套餐包以及围绕软件的差异化营销，再到底盘下灵活的软硬件开发架构、中央计算平台，都成为行业研究和讨论的焦点。如果结合特斯拉的创新案例，软件定义汽车给行业带去的两个最显著冲击体现在：
第一，软硬件解耦，让汽车的物理开发和数字开发并行不悖，但更多的是由软件来定义差异性；第二，软件商品化，无论是以月为频率的软件更新带去的性能提升和新的功能，还是类SaaS的订阅收费，特斯拉目前所代表的新的商业模式尽可能地延长了汽车的生命周期和价值周期。
一部分意识超前的主机厂已经开始战略转型，加快软件能力的建设；而一部分企业出于资金投入、内部转型难度等多方面的考虑，对向软件转型仍报以谨慎乐观态度。
为此，本文试图帮助车企厘清“软件定义汽车”的由来，发展背后的推动力，对行业带去的各类变化，转型的阻力，新涌现的行业机会等等，并根据各产业链上的利益主体所处的行业位置、能力构成，提供了几种可行的应对模式和转型路径。希望借此报告能够帮助主机厂、零部件企业、新兴的软件企业看清软件定义汽车的本质和发展脉络，理性应对，按需布局，提前在产业链变革中锁定高利润环节。
 

2、对软件定义汽车的理解
自2018年起全球汽车产业便掀起了关于“软件定义汽车”的讨论，2019年大众汽车CEO赫伯特·迪斯更是提出大众将成为一家由软件驱动的公司，这也正式标志着行业开启了向软件转型的大幕。自此之后，市场对于软件定义汽车有诸多解释，既有专注于整车OTA（空中升级，OverThe-Air）体系建设、自研操作系统的讨论，也有对电子电气架构、基础软件平台的详细拆解。
对此，本文希望在多方解读的基础上试图给出一个更全面、更深入的理解：“软件定义汽车”从表面上看是车内软件（包括电子硬件）的数量、价值超过机械硬件，背后更多的反应了汽车从高度机电一体化的机械终端，逐步转变为一个智能化、可拓展、可持续迭代升级的移动电子终端。为实现这一目标，整车在标准操作程序前便预埋了性能超前的硬件，并通过OTA在生命周期中逐步解锁和释放功能和价值。在该背景下，主机厂的核心能力将从机械硬件转向电子硬件和软件；产业价值链也将从一锤子硬件销售转向持续的软件及服务溢价。
首先，软件及汽车电子占整车的研发成本逐步提高，车内软件和电子硬件价值有望超过硬件，成为整车价值的核心。据测算，预计到2030年软件成本占整车BOM（物料清单，Bill Of Material）的比重将从目前不到10%增长到50%。需指出的是，这里的软件除应用程序开发、还包括AI算法、操作系统，以及软硬件一体化程度高的控制器、芯片等电子硬件。
其次，软件及软件更迭所带来的性能和功能变化，将决定未来汽车的差异性。软件的更新维护是未来主机厂提供差异化体验、提升客户满意度最经济、最便捷、最快速的一种方式。前提是由硬件提供冗余，再由软件实现迭代。
最后，包括主机厂、零部件企业等产业链上企业将加强软件能力建设，并围绕“软件定义汽车”开启从产品开发模式、组织架构、人员构成、运营体系等的内部变革。此外，新兴的软件公司将借助软硬件协同能力，兼容产业链上下多方需求，一举跃升为汽车产业链上新的tier-1企业。

3、软件定义汽车的驱动力

3.1 产业发展需要
汽车“新四化”离不开软件和算法随着新四化的深入发展，汽车正加速从从机械设备向高度数字化、信息化的智能终端转变。从监测控制电动车电池包的温度，到运行中控屏上的应用程序，再到人机交互体验，自动驾驶汽车对周围物体的探测与分类等功能的实现，都离不开软件的开发、算法的搭建。以自动驾驶为例，它是一个软硬件高度集成的终端，软件可以理解为自动驾驶汽车的“大脑”，它让各类传感器硬件收集的信息变得有意义，大脑分析这些信息帮助车辆做出最优驾驶决策。而更高级别（L3及以上）自动驾驶的复杂性将显著提升，机器学习算法、深度神经网络模型等的重要性就更为凸显。不同于互联网行业，汽车软件是嵌入式软件开发，意味着每新增一个功能，就要增加对应的ECU（电子控制处理器 ，Electronic Control Unit），并为此开发代码。而无论是智能网联、还是自动驾驶都将引入大量的硬件设备以及与之对应的海量软件开发和数据运算处理工作。因此，车内的软件代码正呈指数级增长，据不完全统计，豪华车因较高的驾驶辅助系统（Advanced Driver Assistance System， 以下简称ADAS）、L2级自动驾驶装载率，其软件代码行数已经超过了1亿行，未来几年内，软件代码数量将从1亿行增至3亿行。
3.2 消费者期待
消费者期待汽车能够延续智能手机的行为习惯和体验中国拥有全球最高的智能手机渗透率，达到了近60%。随着硬件性能的过剩，智能手机的竞争也逐渐转向了软件生态的丰富性、前沿技术的创新应用以及对用户价值的深度挖掘。而近几年无论是从手机厂商对车机的加速渗透，还是汽车制造商对智能、互联、人机交互的研发投入，都可以看出消费者在智能手机上的用户体验和使用偏好已延伸至车载环境，这意味着手机端的竞争发力点也将复制到车机端。智能手机的不断迭代让消费者体验到在不用购买最新款手机的前提下，通过系统升级也能实现性能阶段性的提升、功能的改进。当然对于快速迭代的消费电子产品，OTA模式有利也有弊，其中一个明显的弊端是尽管手机厂商仍然保持着一年一更新的产品上新频率，消费者更换手机的周期却越来越长。但对于更换频率至少5年起步的耐用消费品而言，OTA能够却能让汽车在全生命周期都能实现持续的性能优化和功能升级。
3.3 价值链转移
硬件加速“商品化”，软件才能实现更高附加值同智能手机等其他硬件制造行业一样，汽车产业也在经历“硬件商品化”的过程。随着汽车产业进入重大技术变革，再加上复杂汽车电子技术的兴起，一些传统机械零件正加速商品化和白标化，即硬件所能实现的差异性越来越小，硬件销售的利润越来越薄。受此影响，内燃机业务占比较大的全球零部件巨头在过去三年间股价下跌了约3成。而同一时期，软件、服务在产业链的重要性却愈发凸显，包括自动驾驶全栈道软件企业、高精度地图厂商、AI芯片等半导体硬件企业在资本市场上掀起一阵热潮，据不完全统计，2016-2019年四年期间，全球自动驾驶企业投融资多达374起，吸引融资额234亿美元。苹果手机凭借App Store、操作系统、数字产品和服务建立了强大的软件生态体系和可持续的收入模式，汽车产业也正逐步从一锤子硬件销售转向“持续的硬件升级、订阅服务”等盈利模式。近几年，硬件预埋+FOTA （固件空中升级，Firmware Over-The-Air）模式的兴起，让主机厂开始重新审视OTA的价值。通过预埋性能和配置更超前的硬件，等算法成熟、软件完善，车主能够在不更换汽车的前提下靠OTA就能激活隐藏的性能、拓展新的功能。上一轮车联网发展历程中，OTA也被重视过，但仅限于IVI （车载信息娱乐系统， In-Vehicle Infotainmen） 应用程序、操作界面更新（即SOTA， 软件空中升级，Software Over-The-Air），远程更新并未给消费者带去实用性的增值体验。随着FOTA技术的不断成熟、再加上硬件变得商品化、标准化，硬件带去的差异化体验加速被抹平。主机厂意识到必须利用软件、软件所能释放的新功能、新的商业模式给消费者不同的体验和价值。
以特斯拉为例，软件服务在公司的营收和利润占比中开始扮演越来越重要的角色。特斯拉的软件收入除了传统的车联网服务（数据流量+车载内容/服务）之外，还包括了OTA付费升级和软件选装包。2019年以来，特斯拉开始积极尝试 OTA 付费升级，典型案例就是加速性能升级包的推出，Model 3车主只要付费3,000美元，即可将汽车的百公里加速性能从4.6s 提升到4.1s。而更受车主青睐的自动驾驶选装包，则有望成为未来特斯拉最主要的软件收入来源。目前，特斯拉计划将自动驾驶选装包的收费模式从一次性前装收费转变为订阅服务这种持续收费模式。预装FSD硬件的特斯拉车主只需每月支付100美元即能解锁该服务。一旦完成软件订阅服务的商业模式转换，每辆激活 FSD 的销售车辆都有望为特斯拉贡献持续的现金流。

 

图一：软件收入未来有望成为特斯拉营收的重要来源

4、现状与未来的差距

4.1 汽车软硬件架构难以适应软件定义汽车的发展需要

电子电气架构面临算力束缚、通讯效率缺陷、以及不受控的线束成本黑洞

自汽车产业首次引入ECU以来，整车的机电一体化、电气化水平已经取得较大幅度的提升。从最初仅控制发动机工作，到后期延伸至底盘悬挂、车身电子控制、以及同车辆性能无关的信息娱乐、网络通讯等车载装置，如今每个车载功能对应一个或多个ECU。随着近年来燃油经济性、安全性、舒适性、娱乐性等需求的提升，电子控制器的数量更是进一步增长，目前L2级豪华品牌汽车上ECU数量已经达到100多个。

在机电一体化发展初期，整车电子电气架构（EEA，Electronic & Electrical Architecture， 以下简称E/E）多采用分布式模式，即传感器、ECU和执行器一一对应，分布式形态确保了系统的抗干扰性和独立性。但随着汽车不断向智能化、网联化方向发展，以单片机为核心的传统分布式电子电气架构已经很难满足未来智能汽车产品的开发需求，具体表现存在以下几方面痛点：

首先，分布式电子电气架构无法满足未来更高车载计算能力的需求。

ECU是基于微控制器（MCU，Microcontroller Unit）和嵌入式系统的电子控制单元，MCU是一种微型计算机，而嵌入式系统主要是用于控制不适用于计算。因此单个ECU仅能处理数据量较小的运算和控制工作，例如发动机控制、电池管理、电机控制等局部功能。但未来无论是智能网联，还是自动驾驶，对整车开发带去的一个巨大考验便是爆炸式的数据处理需求和更高的运算速度。尤其是自动驾驶技术的发展，还将出现复杂的逻辑运算和非结构数据处理场景，现阶段L2级自动驾驶软件计算量已经达到10个TOPS（Tera Operations Per Second）量级，预计L4级需要的算力将超过100 TOPS。显然当前微计算机的算力资源难勘其重。分布式架构的缺陷还体现在各控制器之间的算力无法共享。由于一个传感器对应一个ECU的封闭开发特点，导致各控制模块之间的算力无法共享，这也意味着处理相似功能逻辑时，算力资源难以实现最优分配，造成大量运算资源浪费。

其次，驱使EEA架构升级的另一个推动因素来自于更高的通讯效率和更大的带宽容量需求。

当前的电子电气架构是基于信号的架构设计，各ECU之间通过CAN（Controller Area Network）总线进行信号传输。CAN总线技术的强项在于简洁稳定、成本低、抗干扰性强、安全性高，单一节点的故障不会扩散到整个网络。但随着车内传感器数量的增加，智能座舱等对车载网络带宽和时延的需求提高，不仅数据传输需求总量井喷，还要求能以更高的速率进行数据间的通信。例如在自动驾驶多传感器融合方案下，不同传感器（激光雷达、雷达、摄像头等）需要实时的信息处理和融合，这就要求更高的通讯带宽和传输速率。目前，CAN总线的工作速度是每秒兆比特，相比之下，新的通讯技术以太网能够允许传感器数据以每秒千兆比特的速度传输。

最后，成本管控黑洞。

随着车内ECU、传感器数量增加，整车线束成本和布线难度也跟着大幅提升。在实现L3级以上高级别自动驾驶时，车内将引入更多的硬件传感器，除了ECU数量增多之外，线束布置、安装也不得不重新设计，而过于复杂的线束布置将带去更高的机械结构的成本，推升整车BOM成本，同时还影响自动化生产效率。由此可见，无论是对更强大的算力部署、更高的信号传输效率需求，还是出于车身减重和成本控制的考量，都要求汽车电子电气的硬件架构从传统分布式朝着“集中式、轻量精简、可拓展”的方向转变。

图二：汽车电子电气架构升级路径图

最早提出E/E架构概念的零部件厂商已经开始为主机厂寻求电子电气架构的升级探索出了路径图 （图三）。博世将整车E/E架构分为六个阶段，首先将经历“模块化” 和“集成化”阶段，继而向“域集中”方向演进，接着是“区集中”和中央计算，最后实现车云计算9。集成化能做到让一个ECU对应多种功能，削减了一定数量的单一功能的控制器，但模块化的封闭架构设计仅能满足L2以下自动驾驶，无法应对更高级别自动驾驶的算力和功能安全需求。

“域集中”可分为两个阶段：初期按硬件模块所处功能域分配，例如动力域、底盘域、车身域、信息娱乐域和 ADAS域的经典五域的划分。每个域配备一个算力强大、控制范围更广的域控制器（Domain Controlller Unit，以下简称DCU），通常搭载多核处理器。ECU数量上得以大幅减少，功能也得以简化。不过，对于一些计算要求低、但实时性和安全性要求高的功能，仍将由ECU来控制。域内部通信将沿用CAN总线等车载网络，域之间通信则引入以太网技术。

后期“跨越融合”是将具有相似功能安全等级和信息安全级别的域控制器进一步融合。例如将原动力、底盘、车身域整合为“车辆控制域”，负责整车控制以及高实时性、高安全性功能的实现；“智能座舱域”则取代原来的信息娱乐域，负责人机介面交互、车载T-box整合相关功能；“智能驾驶域”则负责高级别自动驾驶相关的感知、规划、决策相关功能的实现。“区（Zone，区别于域的概念）集中”是一个较特殊的阶段，但也是最早接近整车中央计算的雏形。在该阶段，电子电气架构布局实际上以线束（整车物理区域）为导向，主机厂根据模块化考虑，在车辆的主体里尽可能把功能分类组合好，把软件配置在中心化的区域核心控制器中。最后，整车计算资源集中到少数几个中央计算单元，统一调度各类传感器、执行器。

如果进一步精简，汽车电子电气架构中的硬件架构将主要经历三个演变周期：集成化、域集中式（DCU和MCU两个时期）和中央集中式（如图所示）。目前，主机厂已经根据自身掌握的技术能力、研发实力（主要是软件人才占比）、同零部件企业的供应关系、成本平衡等多方面原因，开启了截然不同的转型路径。

图三：主流汽车制造商电子电气架构升级路径对比

根据车企的公开规划，我们总结出了三种升级类型：第一类“一步到位型”，即跳过域集中阶段，直接走向车载中央计算，典型代表是特斯拉。以特斯拉为例，Model3采用了区控制器（Zone Controller）配合车载中央计算处理器（CCM，Central Control Module）的模式，CCM整合了驾驶辅助系统（ADAS ）和信息娱乐系统 （IVI ）两大模块，剩余的域功能则根据物理位置就近布置（由左右两个车身控制模块负责），大幅减少车辆的线束成本。区控制器，在实现计算集中化需求的同时，还实现了整车物料成本平衡。第二类“激进型”，具体表现为不满足于tier-1给出的渐进式升级路线，根据主机厂认为的最优方案布置控制器，例如大众。第三类“按部就班型”，这类车企相对保守，基本沿袭tier-1企业给定的路线进行升级。

汽车将遵循IT行业规律，软硬件解耦整车电子电气架构升级的另一个驱动因素来自于软件层面。目前，无论是离散式的电子电气架构，还是汽车软件开发模式（ECU控制器采用嵌入式系统，即软硬件高度耦合，多以“黑盒模式”由供应商交付给主机厂），都很大程度限制了整车OTA功能的实现、应用生态的拓展以及未来未来主机厂掌握更高程度的软件开发主导权。具体而言：

首先，汽车软件的模块化、平台化程度低，导致软件资源无法集中调度、协作性差。

主机厂的ECU通常来自于不同的零部件供应商，事实上控制器上许多底层软件的重复性很高，这些代码主要保障控制器的正常运行，例如CAN总线信号的收发、任务进程的调度、Flash数据的读写等等。但碍于每一家供应商的软件编程语言不同、接口标准不同，而且软件又和硬件高度依赖，使得这些底层代码无法被复制和移植，从而造成ECU软件开发的大量重复和资源利用的低效。

其次，软硬件高度嵌套、主机厂无法执行大规模、深层次的更新和升级或定制化开发工作。

分布式软件架构是一种面向信号的架构，控制器之间通过信号来传递信息，但整个系统是封闭、静态的，在编译阶段就被定义死，因此当发生例如主机厂要修改或增加某个控制器的功能定义，同时该指令还必须调用另一个控制器上的功能时，就不得不把所有需要的控制器都升级，大大延长开发周期、增加开发成本。

也正因此，汽车软件开发将遵循IT行业的发展规律，引入中间件技术、虚拟化技术来实现软件模块化、硬件抽象化和标准化，从而进一步解锁软硬件的耦合关系，满足电子电气架构灵活、可拓展的需求。具体来看，中间件（Middleware）是指一种将不同硬件依赖度的软件进行封装实现软件模块化、并且通过定义了一系列标准应用程式介面（API）实现软件分层化的技术。它上层应用软件和底层基础软件的解耦，提高了软件的复用性和可扩展性，降低产品开发的复杂度和风险。例如应用软件开发者只需专注于具体应用功能的开发，无需理会控制器底层软件的差异。汽车软硬件解耦引发的更深入的变革是将当前基于信号的软件架构，逐步朝面向服务的架构（SOA， Service-oriented Architecture）转型。SOA的本质是各控制器上的软件将无视于其上的硬件平台、操作系统，以一种抽象服务的形式贡献出来，供其他软件组件调用。

4.2 传统瀑布式开发模式面临较大的局限性

基于以上技术架构方面的变化，在软件定义汽车的背景下，汽车研发将由传统的瀑布式开发向敏捷开发的模式转变

在“软件定义汽车”的过程中，汽车作为一个智能移动终端的消费电子品属性变得越来越明显，对开发成本和开发周期的控制都提出了新的要求，同时在车辆交到消费者手中后，产品的迭代才刚刚开始。而传统的汽车研发生态链则是线性的，遵循了瀑布式的产品开发模式，到SOP产品研发基本结束。在传统的瀑布式开发模型下，汽车软件的开发工作基于功能模块被分割成为不同部分平衡进行，而不同的部分开发团队会在自身领导的带领下集中负责开发一个功能，再按整体进度顺序开展每个开发阶段，就如瀑布一样的流水线式运行。由于各开发部分之间相对独立，很容易造成“谷仓效应”，更多只在部分内部展开局部性优化，缺乏系统级/平台级的开发全局观，很难做到整体的优化；同时各部分的开发时间都不一致，就需要一个自上而下的工作架构，并制定十分完善的前期开发顺序规划才可以让开发工作有序的进行，而这种工作架构造成了业务结构和组织结构的分离，需要很好的内部协调开展工作协同，而且各部分之间的进度顺序依赖很容易造成队列效应，一旦出现某个部分开发发生延误时，便会影响整体的开发进度。这些问题在实际工作中具体表现在每个部分周期过长的开发阶段都对应一个独立的测试阶段，再逐层细化、分级验证，开发和测试无法同步进行，而每个阶段都过于依赖上个阶段成果，使得流程僵硬，导致开发成本较高且周期过长，而这些都是与“软件定义汽车”要求主机厂必须缩短产品上市周期、产品基于消费者需求、支持不断的迭代、对市场需求迅速反馈等相矛盾，突显出了传统瀑布式开发的局限性。

而以往更多应用于纯软件开发环境下（如软件公司等）实施的敏捷式开发模型在此时因其自身特点就显得更加适合“软件定义汽车”的要求。在敏捷式开发模型下，开发团队以产品特性分工，每个团队会端到端的开发所负责的产品特性，包含有关该特性的所有功能，各团队均有一定的自由度和决策权，而当不同产品特性之间牵涉到共通的产品功能时，各个开发团队便需要在这些区块上组建跨产品特性协作群落，展开合作开发，达到整体优化的效果。同时敏捷式开发模型下的业务结构和组织结构构成流线型，既有利于达到密切的协调合作，最大限度地减少管理成本，同时因其灵活的工作模式，使开发团队可与客户实现高度互动，采用最低可行性产品（MPV， Minimum Viable Product）的形式快速满足用户需求，并在使用中不断创新迭代。这些特点都与“软件定义汽车”的要求不谋而合。

但是，需要注意的是不同于纯软件开发环境，汽车工业有其特殊性和复杂性，“软件定义汽车”毕竟还是要落脚于软件与汽车硬件实体的结合上，这就要求敏捷式开发模型在汽车工业的应用中需要面临硬件开发与多供应商环境下的复杂挑战。作 为“软件定义汽车”下及敏捷式开发的实践者—特斯拉，为行业提供了具有参考价值的经验，除了软硬件开发周期分离之外，还包括在产品设计之初就提前将软、硬件预先设计好，在标准操作程序时候充分考虑未来功能扩展需求，把将来用于扩展功能所需的标准化硬件预置，后续通过软件的升级或者功能的开发来解锁硬件所搭载的功能。比如Autopilot提前预装硬件，待OTA更新解锁内置功能，并支持全生命周期软件更新。

4.3 组织结构和人才供给是汽车向软件转型的一大短板

从根本上重塑主机厂面向功能的组织转向的组织构架，从平台型开发组织。

自宣布面向软件驱动以来，一些主机厂便启动了组织结构层面的调整。例如大众汽车在2019年6月创建了全新的Car.Software软件部门，计划招聘软件相关人员近5,000人，并宣布未来3-5年内在软件组织架构方面整体的投入70亿欧元。丰田是另一家实质性地推进向软件转型的主流汽车制造商，今年年初成立了一家新的控股子公司Woven Planet Holdings和两家运营子公司，专注于自动驾驶、新的汽车操作系统以及高清地图等软件业务的开发。各主机厂正积极引入包括软件、算法、车联网、自动驾驶、AI工程、电子工程等软件复合型人才，确保能快速对现有人才队伍结构进行调整，增加软件工程师的比例，确保企业在向软件转型、产品创新过程中保持竞争力。

国内方面，上汽是少数几家做出向软件方向战略转型的主机厂。去年年初上汽集团成立了软件中心 —“零束”，未来将聚焦在智能驾驶系统工程、软件架构、基础软件平台和数据工厂等项目。这家新成立的软件公司现在已扩充至1,000人，到2023年团队规模攀升至2200人。其他几家国内主机厂尽管未成立独立的软件子公司，但从新进招聘岗位来看，相当高比例均为软件相关。例如广汽研发中心超过90%的招聘岗位为软件相关工程师。

成立单独的软件子公司从事软件开发，能够较好的发挥自主性和独立性，充分释放组织活力。而对于只在集团内部成立了软件队伍的车企而言，还需要进一步推动公司内部组织架构调整、优化整车软件开发流程。例如建立一个自上而下驱动、基于共同目标或战略、能协调跨部门合作、平台型的软件开发组织。汽车工程开发是按照功能模块来划分的，如动力总成、底盘和车身、信息娱乐，而且多为独立开发。但随着汽车电子电气架构朝“域中心”、“中央集中”方向发展，ECU数量的减少，而域控制器或中央计算平台又是以分层式或面向服务的架构部署，预计未来的汽车电子软件开发也将按层的方式重新划分。

目前，汽车软件人才的人才供给渠道狭窄，缺口较大。汽车电子软件开发属于嵌入式软件的一个分支，行业相对封闭，从业人员来源相对较窄。嵌入式软件开发人才多数去了互联网企业，但不懂硬件，缺乏汽车工程、汽车软件的知识。几方面因素造成汽车软件工程师高度紧缺的状态。此外，对于自动驾驶软等技术仍在变化、商业模式不明的领域，企业还需要改变其招聘模式和人才管理模式，例如从岗位为中心到向以人才为中心转变；同时在工作内容设置、绩效管理和激励上也应当高度的弹性和灵活性。

4.4 来自供应链体系的阻力

零整关系将从塔状垂直走向环状扁平

图四：“软件定义汽车”趋势下供应链关系的变化

对于主机厂而言，借助一级供应商能够迅速实现和落地产品功能。例如在对初级自动驾驶（即L2级+以下系统）的研发投入上，考虑到包揽所有开发工作的成本太高，也不具备技术优势，多数厂商采取了Tier-1供应商的解决方案。而国际零部件巨头凭借其多年的工程能力、产品化能力、成本控制经验，无论是自动驾驶感知和决策层面（例如毫米波雷达、单双目摄像头等传感器和系统），还是控制层面（线控系统），都拥有达到车规级别且成熟的量产产品。因此在辅助驾驶阶段，主机厂普遍倾向于直接采购Tier-1企业提供的集传感器、芯片和算法的软硬件一体化产品和方案。目前在ADSA的能力实现上，大量新上市车型搭载了Mobileye的视觉芯片，可以说多数主机厂L2级自动驾驶方案的视觉模块能力完全来自于供应商。但供应商模式也逐渐呈现出诸多弊端：例如国际零部件企业的ADAS方案本土化能力相对较弱、对客户需求的快速响应能力不足；另一方面，零部件厂商的开放程度有限，在过去很长一段时间Mobileye都采取算法和芯片捆绑销售的模式，不支持主机厂自定义内部算法，这在很大程度上限制了主机厂进行定制化和差异化的开发，导致其产品创新力不足。

基于上述背景，重塑当前零整关系的驱动力越来越多源自于主机厂希望对自动驾驶技术实现自主、可控。尤其是进入到高级别自动驾驶阶段，汽车软件的地位和重要性的不断提升，汽车厂商已经不能满足于黑盒供应模式，而是希望自上而下定义需求、功能和标准，分软件、硬件、系统单独采购，并要求在核心技术上能够穿透Tie-1的技术壁垒，直接同核心底层零部件企业建立合作。在该新兴趋势驱动下，近几年国内外主机厂以参股或战略合作的形式，同包括自动驾驶全堆栈企业、AI芯片厂商、激光雷达等传感器企业缔结了或强或松的绑定关系。

另一小部分研发实力更强、更具进取心的汽车制造商，出于对技术领先性和差异化的担忧，更是选择从底层搭建软件基础设施，从核心零部件到系统级都采取自主开发和垂直整合的方式推进，投入巨大。自研方案允许主机厂不再受限于供应商技术以及硬件的性能瓶颈和开发周期束缚，让最先进的处理器上车，迭代软件的同时迭代硬件。

而无论是同核心软件、电子硬件企业建立合作，还是自主研发、垂直整合，传统供应链关系都将发生根本性的变化。车企与子级供应商的协作将进一步加深，打破Tier2到Tier1再到OEM的塔状供应模式，向扁平化的供应网络模式发展。

---

本文节选自德勤的白皮书《软件定义汽车—箭在弦上的产业变革》,

来源：汽车电子与软件，原文链接：https://mp.weixin.qq.com/s/jsqOE0VF7wnkNTAs0dDYcA

原文链接：https://bbs.z-onesoft.com/omp/community/front/api/page/mainTz?articleId=7652