图一：软件收入未来有望成为特斯拉营收的重要来源
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的塔状供应模式，向扁平化的供应网络模式发展。
最前沿的电子设计资讯
