万字与你深度了解软件定义汽车

lixinfu

新一轮科技革命和产业变革方兴未艾，作为新技术集成应用最佳载体之一的汽车正加速向智能化转型，智能汽车已成为全球汽车产业发展的战略方向。整车电子系统功能复杂度呈指数级上升，软件占比持续增大。有数据显示，2010 年主流车型约含1 000 万源代码行数，而2016 年达到约1.5 亿行。2018 年软件约占D 级车或大型乘用车整车价值的10%，据摩根士丹利估算，未来软件价值占比将达到60%左右。整车技术与工程核心正从传统硬件层面转移到软件，大众汽车表示，软件创新将占未来汽车创新的90%左右。车辆架构正朝着以通用计算平台为基础、面向服务架构的方向发展。未来车辆差异化将更多体现在软件和先进电子技术赋能的用户交互界面和体验层面，软件将带动汽车技术革新，引领产品差异化。软件定义汽车（software defined vehicles，SDV）是大势所趋。软件定义汽车具体是指在模块化和通用化硬件平台支撑下，以人工智能为核心的软件技术决定整车功能的未来汽车。软件定义汽车功能的增加与升级可通过软件的远程部署与更新来实现，汽车硬件将成为模块化、通用化的平台和资源池，支撑整车软件多样化开发与部署。软件定义汽车已引起业内外广泛关注，但尚未有文献提出软件定义汽车的整车开发、整车物理结构、整车信息结构，软件定义汽车技术体系也无明确架构。本文中提出软件定义汽车整车开发、整车物理结构以及整车信息结构，并总结提出软件定义汽车技术体系。



整车开发1.1 整车开发流程

1.1.1 传统汽车整车开发流程整车开发流程界定一辆汽车从概念设计经过产品设计、工程设计到制造、最后转化为商品的整个过程中各业务部门的责任和活动，是构建汽车研发体系的核心。传统汽车开发流程一般包含策划阶段、概念设计阶段、工程设计阶段、样车试验阶段和量产阶段。目前，国际汽车厂商的研发流程已有成熟模板，图1展示了通用汽车的全球整车开发流程。

图1 通用汽车全球整车开发流程1.1.2 软件定义汽车整车开发流程软件定义汽车整车开发流程在整体上仍包含上述5个阶段，但具备以下显著不同点。软件开发比重将大幅增加。据摩根士丹利估计，未来软件价值占比可能达60%左右。此外，大众汽车表示，到2030 年软件开发成本将占整车开发成本的一半左右。软硬件开发解耦，但持续协同，如图2 所示。软件定义汽车通过软硬件开发的有效解耦与持续协同，使软件开发、验证、交付等不依赖于整车硬件开发进度，在开发各个阶段都能即时释放软件产品。

图2 软硬件解耦、持续协同硬件开发向架构化、模块化、工具箱策略趋势发展，如图3所示。当前国内外主要车企在整车开发上都注重发展平台化，将不同产品的子系统、零部件通用化。架构化、模块化的概念则基于平台化，当平台数量过多时会导致冗余浪费，通过研究平台间的关系，形成统一架构整合各平台。平台化的概念侧重于物理上的共用零件，而架构化的概念侧重于设计过程上的同方法和制造过程中的模块化。工具箱策略则是指不论车辆尺寸和性能，各种车型都可以通过已有整车开发工具箱内的模块集成拼装组成。

图3 大众汽车平台模块化战略（图片来自大众）从开发策略与汽车等级的关系角度来看，平台化是单汽车等级的协同增效，底盘件共用等策略化仅适用于特定汽车等级的开发，架构化和模块化适用于多汽车等级的开发，工具箱策略则覆盖所有汽车等级的开发需求。用户需求导向的定制化开发。软件定义汽车将从单一交通工具转变为用户的第三生活空间，整车开发将更加注重用户需求，以用户需求为导向。总体上，软件定义汽车整车开发流程是双闭环开发流程，包括车辆开发与软件迭代两个层面，如图4 所示。车辆开发主要是指新车的开发阶段，总体上包括策划阶段、概念设计阶段、工程设计阶段、样车试验阶段、量产阶段等；软件迭代主要是指在用户使用阶段，通过交互评价数据采集、用户画像构建指导软件开发，利用OTA 远程升级等技术进行软件远程更新迭代。

图4 软件定义汽车双闭环整车开发流程软件定义汽车整车开发流程形成双闭环，第一个闭环是指通过交互评价数据采集、用户画像构建可指导新车开发，另一个闭环是指用户使用阶段可以借助OTA技术实现软件持续更新迭代。在车辆全生命周期中，软件迭代过程持续进行，因此整车开发也成为具备生命力的持续开发过程，直至车辆报废。1.2 整车开发模式

1.2.1 传统汽车整车开发模式传统汽车整车开发模式是一种V 型开发模式，如图5所示。V型左侧涵盖需求分析，右侧对应模块测试，可在软硬件模型完整构建前完成集成测试方案设计，并有效保证测试方法与对应模块的兼容性，高效定位测试问题。但传统V型开发模式中“整车-系统-子系统-软硬件”的开发设计顺序局限于有明确需求导向的整车开发，难以适应软件定义汽车功能快速迭代的需求。1.2.2 软件定义汽车整车开发模式

图5 传统汽车整车开发模式软件开发对软件定义汽车整车开发模式的构建举足轻重。传统迭代式软件开发模式下，每一次迭代都遍历需求分析、分析设计和测试等流程，并产生最终产品的一个子集。多期不间断的迭代使产品更适应多变的需求。此外，敏捷开发、螺旋式开发等软件开发模式也能提升软件产品的开发效率。软件定义汽车整车开发模式如图6 所示，将结合传统软件开发和整车V 型开发模式的优点，具备快速迭代、持续集成、并行开发、多平台适用及用户个性化等特点。软件定义汽车开发模式中，首先进行系统解耦分析，将整车解耦为子系统进行需求分析，然后进入持续集成开发阶段，按照“设计-开发-测试-发布”循环往复进行，持续将软硬件集成至系统主干上，最终完成发布。在持续集成开发阶段，各类开发工具平台如CarSim、PreScan、CARLA 等的适用性可使整车开发效率大大提升。

图6 软件定义汽车整车开发模式整车投入使用后，根据用户反馈情况进行快速迭代，再次遍历“系统需求分析-持续集成”的流程并通过OTA技术完成功能发布。软件定义汽车整车开发模式继承了传统软件开发模式的优势，通过并行开发、持续集成，高效利用多开发工具平台的优势，可极大提升整车系统的开发和测试效率。同时，利用快速迭代的软件开发模式可使用户个性化需求得到最大程度的满足，使整车开发贯穿全产品使用周期。



整车物理结构整车物理结构具体是指车辆中的物理硬件机械结构，包括动力系统硬件、底盘硬件、传感器、控制器、执行器、车身和座舱等。2.1 传统汽车整车物理结构

传统汽车的整车物理结构主要由发动机、底盘、电气设备、车身等4个部分组成，如图7所示。

图7 传统汽车整车硬件架构组成发动机是传统汽车的心脏，为汽车提供动力。底盘负责支承、安装发动机及其各部件、总成，形成汽车的整体造型，承受发动机动力，保证正常行驶。电气设备负责起动控制、点火控制、照明与信号系统、电动辅助控制等，主要包括蓄电池、发电机、起动系、灯光与信号系统、信息显示系统、辅助电气系统、电子控制系统等。车身包括车窗、车门、驾驶舱、乘客舱、发动机舱、行李舱等。2.2 软件定义汽车整车物理结构软件定义汽车整车物理结构主要包括动力系统、环境感知系统、决策规划系统、控制系统、智能座舱等。值得注意的是，软件定义汽车整车物理结构具有可被定义性与可被定义级别。软件定义汽车整车物理结构作为通用化的硬件资源池，支持各种软件功能的实现。软件定义依据软件功能种类、复杂度的不同具有不同级别，进而对整车物理结构的要求不同，因而整车物理结构可被软件定义。整车物理结构的可被定义级别越高，整车能支持越多、越复杂的软件功能。从整车开发角度来看，整车物理结构的可被定义级别将成为一个开发选项，能够针对不同需求的用户群体进行专门开发，促进整车硬件开发的定制化。下面对软件定义汽车整车物理结构的主要组成部分进行简要梳理。（1）动力系统近年来，多国陆续出台禁售燃油车或支持新能源汽车的政策，电动化具有促进能源多样化、提高能量转换效率、具备更大减排潜力等优点，是汽车动力系统的未来发展趋势。在我国，新能源汽车包括纯电动汽车、插电式混合动力汽车与燃料电池汽车。相比传统汽车以发动机为主的动力系统，未来软件定义汽车将以上述电动化动力系统为主。（2）环境感知系统自动驾驶技术是车辆智能化的核心体现，主要包括环境感知、决策规划和车辆控制3 大部分，软件定义汽车整车物理结构将涵盖环境感知系统、决策规划系统和控制系统。环境感知系统主要包括车身状态感知、交通状态感知、车辆同所有交通参与者（vehicle to everything，V2X）网联通信等。车身状态感知主要有车辆速度、角度传感器、组合导航系统等，通过传感器获取车辆实时运行状态，并作为输入信息提供给后续模块。交通状态感知主要包括各种环境感知传感器，如相机、激光雷达、毫米波雷达、超声波雷达等。多种传感器可通过数据融合技术克服单一传感器缺陷，提升感知综合性能。V2X网联通信使自车能够与外界车辆（车车通信，vehicle to vehicle，V2V）、道路设施（车路通信，vehicle to infrastructure，V2I）、行人（车人通信，vehicle to pedestrian，V2P）等进行通信。V2X 网联通信强调车辆、道路和使用者3 者之间的联系，通过实时获取交通信息，提升安全性和效率。（3）决策规划系统决策规划系统硬件主要是高性能的计算单元，如CPU、GPU、FPGA、ASIC 等。车辆在行驶过程中，计算单元负责实时处理传感器采集的数据。在自动驾驶算法初研阶段可采用工控机集中计算。其集中式计算架构有利于初期算法研发，但体积大、功耗高、不适于量产的缺点也限制了进一步的应用。嵌入式域控制器是适用于算法较成熟后的自动驾驶计算解决方案。软件定义汽车内部计算量显著增大，通过将汽车划分为功能域，各域包含一个域控制器负责该域的计算，可减少各模块及功能间的相互干扰，提升安全性。此外，融合固化的算法制作专用芯片，可有效集成传感器和算法，直接处理原始数据，从而减轻后端计算平台的计算负荷，降低芯片功耗。（4）控制系统控制系统负责控制车辆速度与转向，使车辆跟踪预先规划的速度曲线与期望路径。传统控制方法包括PID 控制、滑模控制、模糊控制、模型预测控制、自适应控制、鲁棒控制等。与传统车辆相比，线控技术将被更多地用来控制车辆转向、制动、油门等，其主要特征是执行机构与操纵机构没有直接的机械连接，驾驶员的驾驶意图将直接转换成对应的电信号驱动执行机构的精确运动。线控系统技术要求对底盘进行线控改装，目前已具备自适应巡航控制、紧急制动、自动泊车等功能的车辆可借用原有系统而不必过多改装，通过车载网络即可实现控制。（5）智能座舱未来汽车座舱具备成为用户的第三生活空间的巨大潜力。新一代通信技术、人工智能、大数据、人机交互、汽车芯片与操作系统等技术进步将推动智能座舱不断发展，成为软件定义汽车整车物理结构的重要组成。



整车信息结构整车信息结构具体是指车辆中涉及车内外信息通信、软件功能等的结构，包括整车电子电气架构和车载网络、软件架构、车联网等。软件定义汽车整车信息结构自下而上可分整车电子电气架构及车载网络、软件架构和车联网等3层，如图8 所示。整车电子电气架构与车载网络支撑车内信息通信，软件架构实现具体软件功能，车联网则实现车内网、车际网与车载移动互联网的融合。

图8 软件定义汽车整车信息结构3层架构3.1 整车电子电气架构与车载网络

3.1.1 传统汽车电子电气架构与车载网络传统汽车电子电气架构的发展主要经历了3 个阶段，如图9所示。

图9 传统汽车电子电气架构发展历程第1 代分布式电子电气架构采用点对点的链接方式，第2 代分布式电子电气架构实现了功能模块化，第3 代分布式电子电气架构增加了中央网关，实现更广泛的不同功能子系统之间的通信，如图10所示。

图10 第3代分布式电子电气架构车载网络与电子电气架构的发展密切相关，现有主要车载网络类型如表1所示。表1 主要车载网络

控制器局域网络（controller area network，CAN）是汽车专用总线标准，主要用于控制数据传输，是目前在汽车行业应用最广泛的标准。本地互联网络（local interconnect network，LIN）是一种低成本通用串行总线，主要用于车门、天窗等控制。面向媒体的系统传输总线（media oriented system transport，MOST）主要用于多媒体流数据传输。FlexRay 车载网络主要用于容错环境下的线控制动等底盘系统应用。分布式电子电气架构使汽车产业产生了巨大变革，但目前该架构的缺点和局限性也越来越明显，如ECU 底层代码兼容性差、代码冗余、代码复用性差、维护更新困难等，此外，软件定义汽车对高带宽与低延迟的需求显著增长，当前总线网络已不能满足需求。3.1.2 软件定义汽车电子电气架构与车载网络目前正在发展中的新一代电子电气架构是基于域控制器和以太网通信网络的集中式电子电气架构，如图11 所示，这种架构可改善传统电子电气架构及车载网络的问题，适应软件定义汽车需求。

图11 集中式电子电气架构集中式电子电气架构仍划分功能域，各功能域包含强大的域控制器（domain control unit，DCU），域控制器集成了复杂且相对集中的功能，并集成了网关功能。域控制器的核心优势是其芯片计算能力的大幅提升，强大的计算能力使域控制器能够接管域内ECU 的信息计算处理功能，集中汇总、统一处理运算ECU 的数据信息，并将处理后的数据信息发回给ECU执行，这也将促进提升ECU的整合程度。基于域控制器的集中式电子电气架构使用以太网作为主干通信网络，在域控制器下面可保留如CAN、LIN等传统车载网络以太网，以节约成本。以太网具备高带宽，采用灵活的星型连接拓扑，每条链路可专享100 Mb/s及以上的带宽。以太网标准开放、简单，适应未来汽车与外界大量通信和网络连接的发展趋势。以太网灵活、带宽可扩展，适合连接各个子系统，促进车载系统的网络化运营管理。以太网能够降低时间、生产和服务成本，促进产业落地。基于域控制器的集中式电子电气架构和基于车载以太网的车载网络能够满足软件定义汽车对信息处理计算能力、网络带宽的新需求，实现高算力，支撑软件应用持续升级，并增强与云端配合的分布式计算能力。因此，基于域控制器的集中式电子电气架构和基于车载以太网的车载网络很适合成为软件定义汽车的电子电气架构与车载网络。3.2 软件架构

3.2.1 传统汽车软件架构及发展趋势传统汽车电子系统的软件和硬件耦合在一起，ECU 软件的开发测试依赖于硬件，导致开发测试难度较大、灵活性很差。基于此，AUTOSAR Classic 标准被提出，可满足日益复杂的汽车软件需求，在不同的硬件平台上使用相似的软件方案，共享软件组件。AUTOSAR Classic 采用分层体系架构，在微控制器层上分为3 层，即应用软件层、中间件RTE、基础软件，如图12所示。

图12 AUTOSAR Classic体系架构AUTOSAR 分层体系架构实现了软硬件模块独立。中间运行环境RTE 有效隔离了上下层软硬件，提升了软件开发测试效率。面向自动驾驶技术的电子电气架构要求配备具有高性能计算能力的控制器，当前控制器的算力及通信的带宽均需巨大升级。高性能计算能力（高吞吐量，高通信带宽）除了需要硬件架构上如异构多核处理器、GPU加速等支持，也需要适配新的软件架构来支持跨平台的计算处理能力、高性能微控制器的计算以及远程诊断等。此外，V2X 通信应用涉及动态通信及大量数据的有效分配，要求软件架构能够支持云交互以及非AUTOSAR系统的集成。AUTOSAR Classic 无法适应这些新需求，因此在其基础上又出现AUTOSAR Adaptive，基本架构如图13 所示，主要包括应用层、运行层、基础服务层。

图13 AUTOSAR Adaptive体系架构AUTOSAR Adaptive 面向高性能计算处理器架构，其硬件层的算力更高，具有更高的吞吐量。在保证安全等级、降低小部分实时性的情况下，可满足非实时性的架构系统软件的需求，并大大提高了高性能计算处理能力，支持大数据的并行处理、智能互联应用功能。AUTOSAR Classic 及AUTOSAR Adaptive 架构针对不同的应用场景可实现共存和协作，未来汽车很可能采用包含AUTOSAR Classic 以及AUTOSAR Adaptive的异构软件架构。3.2.2 软件定义汽车软件架构软件定义汽车软件架构如图14所示。软件定义汽车软件架构将继承AUTOSAR Classic 与AUTOSAR Adaptive的优点，既支持高安全性、高实时性应用场景，又支撑大数据并行处理、高性能计算应用场景。在结构上延续软件分层架构，按照解决方案设定、软件开发需求的不同，设置不同的概念层。

图14 软件定义汽车软件架构软件定义汽车的中间件将促进应用程序与硬件分离，承担车辆重构、软件安装升级的功能，推动软件抽象化和虚拟化，推动汽车向面向服务的架构转变。软件定义汽车底层操作系统对车企来说具有重要的战略地位，未来缺少自己操作系统的车企可能只能成为代工性质的企业。3.3 车联网

软件定义汽车在车端将朝着完全自动驾驶的智能网联汽车方向发展，如图15 所示，智能网联汽车属于智能汽车与车联网的交集，因此车联网将成为软件定义汽车整车信息结构里的重要一环。

图15 智能汽车、智能网联汽车与车联网等的关系车联网是指车辆物联网，是物联网技术应用于智能交通领域的产物。车联网可实现车与车、车与路、车与人、车与服务平台之间的全方位网络连接［35-38］，全面提升汽车智能化水平。



软件定义汽车技术体系本节提出软件定义汽车技术体系，如图16 所示，软件定义汽车技术体系总体上包括整车物理结构、整车信息结构、整车功能层、软件开发、硬件开发、评价体系等。整车物理结构层主要包括电子硬件、车辆硬件等，整车物理结构层作为模块化、通用化的平台和资源池，为整车信息结构以及整车功能层提供底层支持。软件开发过程注重用户分析、敏捷开发、定制化开发等，主要利用OTA 等技术进行软件远程部署与更新。整车信息结构包括车联网、软件架构、整车电子电气架构及车载网络。软件架构为分层架构，包括应用软件层、中间件、基础软件层等。整车功能层包含具体的整车功能，如信息娱乐功能、智能人机交互、自动驾驶功能、系统更新升级等。用户使用过程中，可通过评价体系对整车功能进行评估，包括主观评价与客观评价等。通过用户分析与评价数据反馈，结合人工智能与大数据分析等技术，进行用户画像构建，进一步指导软件开发。软硬件在结构上和开发上均实现了有效解耦。在整个过程中，整车功能的定义与实现主要通过软件驱动，整车物理结构不再与某个特定功能集成绑定，而是被抽象成可以被软件和服务共享的资源池，从而使汽车由软件来定义。

图16 软件定义汽车技术体系总体上，软件定义汽车技术体系具备以下关键特性：整车软硬件的解耦性、整车物理结构的通用支撑性、整车物理结构的可被定义性、整车功能的软件定义性、整车软件的可远程迭代升级性和交互与评价的数据可采性。整车软硬件的解耦性是指软硬件在结构及开发层面实现了解耦，从而解放软件，提升软件开发效率。整车物理结构的通用支撑性是指整车物理结构成为模块化、通用化的平台和资源池，具备支撑整车软件多样化开发与部署的能力。整车物理结构的可被定义性使整车物理结构根据其软件定义程度的不同而不同，可被定义级别成为开发选项，使整车物理结构具备灵活性和可定制性，以满足多样化需求。整车功能的软件定义性是指整车功能将主要由软件来定义和实现，也即软件定义汽车的基本含义与目标。整车软件的可远程迭代升级性是指软件可通过OTA 等技术实现远程迭代升级，从而改变产品使用模式以及整车开发模式，使汽车具有全周期生命力。交互与评价的数据可采性是指能够采集用户交互与评价体系数据，实现用户分析，满足个性化定制需求。软件定义汽车是大势所趋，本文中分析提出软件定义汽车整车开发、整车物理结构和整车信息结构，并总结提出软件定义汽车技术体系。在软件定义汽车技术体系中，软件定义汽车双闭环开发流程与并行开发模式深入渗透软硬件开发，使汽车成为具有生命力的产品，使整车开发在车辆全生命周期持续迭代进行，整车物理结构与整车信息结构实现有效解耦，整车功能的定义与实现主要通过软件驱动，整车物理结构不再与特定功能绑定，而是被抽象成可以被软件和服务共享的资源池，支撑软件多样化开发与部署，从而实现汽车由软件定义。随着软件定义汽车趋势愈演愈烈，企业纷纷向软件驱动型企业转型，目前来看大家的转型方式主要有三种模式∶模式一，成立软件子公司;模式二，与其他企业联合开发;模式三，内部成立软件部门。模式一：成立软件子公司代表企业：丰田2020年7月，丰田宣布重组丰田研究院高级研发公司TRI-AD并改善业务，正式成立一家新的控股公司和两家运营子公司。新控股公司名为Woven Planet Holdings，将管理另外两家运营子公司Woven CORE和Woven Alpha，2021年1月开始运营。

TRI-AD于2018年3月在日本成立，是丰田与电装、爱信共同出资28亿美元成立的合资公司，其中丰田持有90%的股份Woven Planet Holdings下设三家公司∶ Woven Core和Woven Alpha，其中Woven Core将专注于自动驾驶;Woven Alpha将在互联、车载软件和高清地图等领域开创新业务，孵化创新项目;Woven Capital主要将投资自动驾驶和智能城市等领域，从而为丰田未来城市做准备。

Woven Alpha推出的全新开放式汽车操作系统Arene，它包含了车辆安全所必需的元素和API，并支持从概念到部署的快速开发允许开发人员和OEM以敏捷的方式持续更新软件，同时保持高水平的安全性。Arene是一个车辆软件开发平台，具有最先进的工具、车辆应用程序编程接口 （API）和安全模块，支持快速迭代以缩短从概念到部署的时间。目标是打造地球上最可编程的车辆（The Most Programmable Vehicle on the Planet）



通过Arene，开发人员将能够将相同的代码部署到任何运行Arene OS的车辆，其中包括中间件和硬件抽象层（HAL）。开发人员可以使用丰田的集成开发环境（IDE）开发应用程序，IDE提供工具和服务，包括∶

应用软件开发套件（SDK）：用于将应用程序开发，测试和部署到模拟和真实车辆中的工具和API。应用程序可以访问特定车辆的功能，包括用户界面、传感器和执行器；仿真和测试∶ 使用各种车辆模型创建虚拟场景，并使用Arene 的持续集成和测试管道执行软件在环和硬件在环仿真（SILS和HILS）；基础架构服务：使用丰田基于云的数据管道通过Ansible和Terraform模板处理和索引数据，这些模板可自动创建AWS沙箱；

具体方案：丰田面对智能网联的新需求，丰田汽车设计了基于中央+区域（Central & Zone Concept）概念的电子架构，主要包括三部分;汽车大脑或中控ECUs、车载以太网以及跨区域控制器。

模式二，与其他企业联合开发代表企业：宝马2018年10月，宝马集团与CRITICAL Software公司成功组建了合资公司，名为Critical TechWorks，该合资公司将结合双方在优质移动出行和汽车软件工程方面的专业知识，研发具突破性的车载应用和车外应用。

按照规划，CriticalTechWorks主要研发和运营各个领域的高端软件解决方案，产品范围涵盖车载娱乐信息解决方案和数字服务、量产自动驾驶运输系统、数字销售和数字售后平台、产品数据管理的高端集成解决方案等，以确保在此领域的相关专长和技能。具体方案：宝马通过集成平台实现汽车领域的无缝分层的电子电气架构，在架构中，每类控制器有特定的系统需求且其分类基干需求，采用统一开发方式取代本地方式。

宝马分层式电子电气架构特点：

控制器的分类基于需求调整统一的开发方式取代本地开发方式每类控制器都有特定的系统需求系统级的优化将成为主要焦点，由系统架构师驱动

模式三，内部成立软件部门代表企业1：大众相比国内企业，大众作为全球领先企业，其对软件化变革的嗅觉更为敏感，脚步也更快。去年6月，大众就已宣布成立独立的软件开发部门——Car.Software，以推进集团的数字化转型，正式将软硬件业务以组织变革的方式分离，变革的力度相比国内企业更大。"Car.Software"汽车软件开发部门集结5000多名数字化专家，全面负责车载软件业务，同时，开发更多车载软件和车辆相关服务。大众集团将在2025年实现自主开发的软件比例从现在的不到10%提高到至少60%，旗下的所有车型将配备统一的、拥有全部基础功能的软件平台。"vw.os"车辆操作系统，将成为大众旗下各品牌的标准操作系统。大众汽车云将为"vw.os"系统提供技术支持，首款搭载车型ID.3电动汽车。具体方案：大众MEB电子电气架构相较于MQB平台上采用的分布式电子电气架构，MEB则逐步过渡到域集成架构，包含3个中央电脑，分别为ICAS1、ICAS2和ICAS3，分别负责车内应用服务、高级自动驾驶和娱乐;3个中央电脑之间使用1000Mbit/Sec速率通信，主要的计算是由ICAS1完成。

大众电子电气架构的升级


大众MEB电子电气架构特点：

MEB平台围绕3个中央电脑搭建，分别为ICAS1、ICAS2和ICAS3，ICAS为In Car Application Server；ICAS1主要负责车内应用服务，同时为ECU提供跨网通信能力；ICAS2主要用于支持高级自动驾驶功能；ICAS3负责娱乐系统的域控制器，把导航系统、仪表系统、HUB、智能座舱所有算法和硬件集中于此；3个中央电脑之间使用1000Mbit/Sec速率进行通信；主要的计算是由ICAS1完成；ADAS的传感器与控制器之间采用的是100Mbit/Sec进行通信；执行器之间大多数是通过CANFD进行通信

代表企业2：博世2020年7月，汽车零部件巨头博世（BOSCH）宣布将成立智能驾驶与控制事业部。作为一家一级供应商，博世对于自身角色的定位不再仅仅是为主机厂供应零件的供应商，而是正在从一家传统机械零部件供应商向软件、电子解决方案提供商转型。此前博世提出整车电子电气架构路线图，将整车电子电气架构发展分为6个阶段∶ 模块化阶段、功能集成阶段、中央域控制器阶段跨域融合阶段、车载中央电脑和区域控制器阶段、车载云计算阶段，目前来说，大多数厂商开始从模块化向功能集成阶段迈进。

博世认为"未来生态软件架构"应该包含中间件方案、系统软件技术栈、博世软件包、有助于加速自动驾驶开发的博世AOS和可以下载博世AOS软件的开源社区。其中，中间件方案可以支持软硬件解耦，让整车企业在标准上合作、应用与服务层面充分竞争。

未来生态软件架构——中间件方案系统软件技术栈可以实现应用在汽车终端或云端进行移植，而功能实现不受影响。

未来生态软件架构——系统软件技术栈博世软件包是应用软件和服务的集成，支持软件应用的不同需求、通过标准支持合作开发、通过使用主流软件搭建模块减少软件开发工作量和为实际产品剪裁;博世软件包遵循分层架构，它提供可移植性、 可维护性并分离问题。

未来生态软件架构——软件包博世AOS是一个赋能自动驾驶功能开发、验证和安全执行的中间件和工具，具有更快、更安全、更低成本的特点。

未来生态软件架构——AOS汽车产业链上下对于软件能力的重要性已经达成共识，但在真正向软件驱动型企业转型的过程中，大家都还处于"摸着石头过河"的阶段，软件定义汽车模式的转变，纠其根源是组织形态及技术能力的转变。