软件定义汽车—箭在弦上的变革

1.软件定义汽车背景
在过去的几年里，在现有技术水平下，智能手机和计算机的标准化硬件正逐渐接近物理极限，这促进了其行业从硬件升级到软件开发和迭代，逐步推动硬件设计的更新升级。

诚然，与硬件相对标准化的智能手机和计算机行业不同，汽车行业具有其特殊性。无论是硬件标准化程度还是车辆技术特点的差异，汽车行业都没有完全复制智能手机和计算机行业规律的客观条件，但随着硬件标准化的推进和技术差异化的减少，汽车行业也可能经历类似的过程。
无论是由于客观因素，如生产工艺水平或材料物理特性使硬件设计达到顶峰，硬件性能接近物理极限，还是由于主观因素，消费者对应用软件创新体验越来越敏锐和强劲的需求，促进汽车行业吸引软件技术寻求变革和发展，使硬件技术增加更多的软件价值和品牌。
在这种情况下，软件定义汽车的说法开始在汽车行业流行起来。从消费者的角度来看，特斯拉被认为是这一趋势中最典型的实践者OTA围绕软件的服务、自动驾驶包、差异化营销，再到底盘下灵活的软硬件开发架构和中央计算平台，都成为行业研究和讨论的焦点。如果结合特斯拉的创新案例，软件定义汽车对行业的两个最显著的影响体现在：
首先，软硬件解耦，使汽车的物理开发和数字开发平行，但更多的软件定义差异；第二，软件商业化，无论是月度软件更新带来的性能改进和新功能，还是类别SaaS特斯拉所代表的新商业模式尽可能延长了汽车的生命周期和价值周期。
一些意识先进的原始设备制造商已经开始战略转型，加快软件能力建设；一些企业仍然对软件转型持谨慎乐观的态度，考虑到资本投资和内部转型的难度。
为此，本文试图帮助汽车公司明确软件定义汽车的起源、发展背后的驱动力、行业变化、转型阻力、新兴行业机会等，并根据行业地位、能力，提供几种可行的应对模式和转型路径。希望本报告能帮助原始设备制造商、零部件企业和新兴软件企业看到软件定义汽车的本质和发展背景，合理响应，按需布局，提前锁定产业链改革中的高利润环节。

2.对软件定义汽车的理解
自2018年以来，全球汽车行业一直在讨论软件定义汽车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）、L二级自动驾驶装载率，其软件代码行数已超过1亿行，未来几年软件代码行数将从1亿行增加到3亿行。
3.2 消费者期待
中国拥有世界上最高的智能手机渗透率，达到近60%。随着硬件性能的过剩，智能手机的竞争逐渐转向软件生态的丰富性、前沿技术的创新应用和用户价值的深入挖掘。近年来，无论是从手机制造商对汽车的加速渗透，还是汽车制造商对智能、互联网和人机交互的研发投资，我们都可以看到消费者对智能手机的用户体验和使用偏好已经延伸到汽车环境，这意味着手机终端的竞争力点也将复制到汽车终端。智能手机的不断迭代让消费者在不购买最新手机的情况下体验到了性能的阶段性提升和功能的提升。当然，对于消费电子产品的快速迭代，OTA该模型既有优点也有缺点。明显的缺点之一是，尽管手机制造商仍保持每年更新产品的频率，但消费者更换手机的周期越来越长。但对于耐用消费品，更换频率至少为5年，OTA它可以使汽车在整个生命周期中实现持续的性能优化和功能升级。
3.3 价值链转移
就像智能手机等硬件制造业一样，汽车行业也在经历硬件商品化的过程。随着汽车行业进入重大技术变革和复杂汽车电子技术的兴起，一些传统机械零部件正在加速商业化和白色标准化，即硬件差异越来越小，硬件销售利润越来越薄。受此影响，过去三年内燃机业务占比较大的全球零部件巨头股价下跌了约30%。同时，软件和服务在产业链中的重要性日益突出，包括自动驾驶全栈道软件企业、高精度地图制造商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车主只需支付3000美元，就可以从400公里加速汽车的性能.6s 提升到4.1s。而更受车主青睐的自动驾驶装包有望成为特斯拉未来软件收入的主要来源。目前，特斯拉计划将自动驾驶选装包的收费模式从一次性预装收费转变为订阅服务。预装FSD硬件特斯拉车主每月只需支付100美元即可解锁服务。一旦软件订阅服务的商业模式转换完成，每辆车都会被激活 FSD 所有销售车辆都有望为特斯拉贡献持续的现金流。

/p>

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

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