软件定义汽车技术体系研究

当今，智能汽车已成为全球汽车产业的战略发展方向，汽车技术与工程核心逐渐从传统硬件层面转移到软件层面，软件定义汽车成为未来汽车发展的重要趋势。本文中通过对比分析传统汽车与软件定义汽车，提出软件定义汽车整车开发、整车物理结构和整车信息结构，以及技术体系。

前言

新一轮科技革命和产业变革方兴未艾，作为新技术集成应用最佳载体之一的汽车正加速向智能化转型，智能汽车已成为全球汽车产业发展的战略方向。

整车电子系统功能复杂度呈指数级上升，软件占比持续增大。有数据显示，2010年主流车型约含1 000万源代码行数，而2016年达到约1.5亿行。2018年软件约占D级车或大型乘用车整车价值的10%，据摩根士丹利估算，未来软件价值占比将达到60%左右。整车技术与工程核心正从传统硬件层面转移到软件，大众汽车表示，软件创新将占未来汽车创新的90%左右。

车辆架构正朝着以通用计算平台为基础、面向服务架构的方向发展。未来车辆差异化将更多体现在软件和先进电子技术赋能的用户交互界面和体验层面，软件将带动汽车技术革新，引领产品差异化。软件定义汽车（software defined vehicles，SDV）是大势所趋。

软件定义汽车具体是指在模块化和通用化硬件平台支撑下，以人工智能为核心的软件技术决定整车功能的未来汽车。

软件定义汽车功能的增加与升级可通过软件的远程部署与更新来实现，汽车硬件将成为模块化、通用化的平台和资源池，支撑整车软件多样化开发与部署。

软件定义汽车已引起业内外广泛关注，但尚未有文献提出软件定义汽车的整车开发、整车物理结构、整车信息结构，软件定义汽车技术体系也无明确架构。本文中提出软件定义汽车整车开发、整车物理结构以及整车信息结构，并总结提出软件定义汽车技术体系。

本文内容结构如下：第1章讨论软件定义汽车整车开发；第2章讨论软件定义汽车整车物理结构；第3章讨论软件定义汽车整车信息结构；第4章提出软件定义汽车技术体系；第5章进行总结。

1 整车开发
1.1 整车开发流程
1.1.1 传统汽车整车开发流程

整车开发流程界定一辆汽车从概念设计经过产品设计、工程设计到制造、最后转化为商品的整个过程中各业务部门的责任和活动，是构建汽车研发体系的核心。

传统汽车开发流程一般包含策划阶段、概念设计阶段、工程设计阶段、样车试验阶段和量产阶段。目前，国际汽车厂商的研发流程已有成熟模板，图1展示了通用汽车的全球整车开发流程。

1.1.2 软件定义汽车整车开发流程

软件定义汽车整车开发流程在整体上仍包含上述5个阶段，但具备以下显著不同点。

软件开发比重将大幅增加。据摩根士丹利估计，未来软件价值占比可能达60%左右。此外，大众汽车表示，到2030年软件开发成本将占整车开发成本的一半左右。

软硬件开发解耦，但持续协同，如图2所示。软件定义汽车通过软硬件开发的有效解耦与持续协同，使软件开发、验证、交付等不依赖于整车硬件开发进度，在开发各个阶段都能即时释放软件产品。

图 2   软硬件解耦、持续协同

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

从开发策略与汽车等级的关系角度来看，平台化是单汽车等级的协同增效，底盘件共用等策略化仅适用于特定汽车等级的开发，架构化和模块化适用于多汽车等级的开发，工具箱策略则覆盖所有汽车等级的开发需求。

用户需求导向的定制化开发。软件定义汽车将从单一交通工具转变为用户的第三生活空间，整车开发将更加注重用户需求，以用户需求为导向。

总体上，软件定义汽车整车开发流程是双闭环开发流程，包括车辆开发与软件迭代两个层面，如图4所示。车辆开发主要是指新车的开发阶段，总体上包括策划阶段、概念设计阶段、工程设计阶段、样车试验阶段、量产阶段等；软件迭代主要是指在用户使用阶段，通过交互评价数据采集、用户画像构建指导软件开发，利用OTA远程升级等技术进行软件远程更新迭代。

软件定义汽车整车开发流程形成双闭环，第一个闭环是指通过交互评价数据采集、用户画像构建可指导新车开发，另一个闭环是指用户使用阶段可以借助OTA技术实现软件持续更新迭代。

在车辆全生命周期中，软件迭代过程持续进行，因此整车开发也成为具备生命力的持续开发过程，直至车辆报废。

1.2 整车开发模式
1.2.1 传统汽车整车开发模式

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

1.2.2 软件定义汽车整车开发模式

软件开发对软件定义汽车整车开发模式的构建举足轻重。传统迭代式软件开发模式下，每一次迭代都遍历需求分析、分析设计和测试等流程，并产生最终产品的一个子集。多期不间断的迭代使产品更适应多变的需求。此外，敏捷开发、螺旋式开发等软件开发模式也能提升软件产品的开发效率。

软件定义汽车整车开发模式如图6所示，将结合传统软件开发和整车V型开发模式的优点，具备快速迭代、持续集成、并行开发、多平台适用及用户个性化等特点。

软件定义汽车开发模式中，首先进行系统解耦分析，将整车解耦为子系统进行需求分析，然后进入持续集成开发阶段，按照“设计-开发-测试-发布”循环往复进行，持续将软硬件集成至系统主干上，最终完成发布。在持续集成开发阶段，各类开发工具平台如CarSim、PreScan、CARLA等的适用性可使整车开发效率大大提升。

整车投入使用后，根据用户反馈情况进行快速迭代，再次遍历“系统需求分析-持续集成”的流程并通过OTA技术完成功能发布。

软件定义汽车整车开发模式继承了传统软件开发模式的优势，通过并行开发、持续集成，高效利用多开发工具平台的优势，可极大提升整车系统的开发和测试效率。同时，利用快速迭代的软件开发模式可使用户个性化需求得到最大程度的满足，使整车开发贯穿全产品使用周期。

2 整车物理结构

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

传统汽车的整车物理结构主要由发动机、底盘、电气设备、车身等4个部分组成，如图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 整车信息结构

整车信息结构具体是指车辆中涉及车内外信息通信、软件功能等的结构，包括整车电子电气架构和车载网络、软件架构、车联网等。

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

3.1 整车电子电气架构与车载网络
3.1.1 传统汽车电子电气架构与车载网络

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

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

车载网络与电子电气架构的发展密切相关，现有主要车载网络类型如表1所示。

控制器局域网络（controller area network，CAN）是汽车专用总线标准，主要用于控制数据传输，是目前在汽车行业应用最广泛的标准。本地互联网络（local interconnect network，LIN）是一种低成本通用串行总线，主要用于车门、天窗等控制。面向媒体的系统传输总线（media oriented system transport，MOST）主要用于多媒体流数据传输。FlexRay车载网络主要用于容错环境下的线控制动等底盘系统应用。

分布式电子电气架构使汽车产业产生了巨大变革，但目前该架构的缺点和局限性也越来越明显，如ECU底层代码兼容性差、代码冗余、代码复用性差、维护更新困难等，此外，软件定义汽车对高带宽与低延迟的需求显著增长，当前总线网络已不能满足需求。

3.1.2 软件定义汽车电子电气架构与车载网络

目前正在发展中的新一代电子电气架构是基于域控制器和以太网通信网络的集中式电子电气架构，如图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所示。

AUTOSAR分层体系架构实现了软硬件模块独立。中间运行环境RTE有效隔离了上下层软硬件，提升了软件开发测试效率。

面向自动驾驶技术的电子电气架构要求配备具有高性能计算能力的控制器，当前控制器的算力及通信的带宽均需巨大升级。高性能计算能力（高吞吐量，高通信带宽）除了需要硬件架构上如异构多核处理器、GPU加速等支持，也需要适配新的软件架构来支持跨平台的计算处理能力、高性能微控制器的计算以及远程诊断等。此外，V2X通信应用涉及动态通信及大量数据的有效分配，要求软件架构能够支持云交互以及非AUTOSAR系统的集成。

AUTOSAR Classic无法适应这些新需求， 因此在其基础上又出现AUTOSAR Adaptive，基本架构如图13所示，主要包括应用层、运行层、基础服务层。

AUTOSAR Adaptive面向高性能计算处理器架构，其硬件层的算力更高，具有更高的吞吐量。在保证安全等级、降低小部分实时性的情况下，可满足非实时性的架构系统软件的需求，并大大提高了高性能计算处理能力，支持大数据的并行处理、智能互联应用功能。

AUTOSAR Classic及AUTOSAR Adaptive架构针对不同的应用场景可实现共存和协作，未来汽车很可能采用包含AUTOSAR Classic以及AUTOSAR Adaptive的异构软件架构。

3.2.2 软件定义汽车软件架构

软件定义汽车软件架构如图14所示。软件定义汽车软件架构将继承AUTOSAR Classic与AUTOSAR Adaptive的优点，既支持高安全性、高实时性应用场景，又支撑大数据并行处理、高性能计算应用场景。在结构上延续软件分层架构，按照解决方案设定、软件开发需求的不同，设置不同的概念层。

软件定义汽车的中间件将促进应用程序与硬件分离，承担车辆重构、软件安装升级的功能，推动软件抽象化和虚拟化，推动汽车向面向服务的架构转变。

软件定义汽车底层操作系统对车企来说具有重要的战略地位，未来缺少自己操作系统的车企可能只能成为代工性质的企业。

3.3 车联网

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

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

4 软件定义汽车技术体系

本节提出软件定义汽车技术体系，如图16所示，软件定义汽车技术体系总体上包括整车物理结构、整车信息结构、整车功能层、软件开发、硬件开发、评价体系等。

整车物理结构层主要包括电子硬件、车辆硬件等，整车物理结构层作为模块化、通用化的平台和资源池，为整车信息结构以及整车功能层提供底层支持。软件开发过程注重用户分析、敏捷开发、定制化开发等，主要利用OTA等技术进行软件远程部署与更新。整车信息结构包括车联网、软件架构、整车电子电气架构及车载网络。软件架构为分层架构，包括应用软件层、中间件、基础软件层等。整车功能层包含具体的整车功能，如信息娱乐功能、智能人机交互、自动驾驶功能、系统更新升级等。用户使用过程中，可通过评价体系对整车功能进行评估，包括主观评价与客观评价等。通过用户分析与评价数据反馈，结合人工智能与大数据分析等技术，进行用户画像构建，进一步指导软件开发。

软硬件在结构上和开发上均实现了有效解耦。在整个过程中，整车功能的定义与实现主要通过软件驱动，整车物理结构不再与某个特定功能集成绑定，而是被抽象成可以被软件和服务共享的资源池，从而使汽车由软件来定义。

总体上，软件定义汽车技术体系具备以下关键特性：整车软硬件的解耦性、整车物理结构的通用支撑性、整车物理结构的可被定义性、整车功能的软件定义性、整车软件的可远程迭代升级性和交互与评价的数据可采性。

整车软硬件的解耦性是指软硬件在结构及开发层面实现了解耦，从而解放软件，提升软件开发效率。

整车物理结构的通用支撑性是指整车物理结构成为模块化、通用化的平台和资源池，具备支撑整车软件多样化开发与部署的能力。

整车物理结构的可被定义性使整车物理结构根据其软件定义程度的不同而不同，可被定义级别成为开发选项，使整车物理结构具备灵活性和可定制性，以满足多样化需求。

整车功能的软件定义性是指整车功能将主要由软件来定义和实现，也即软件定义汽车的基本含义与目标。

整车软件的可远程迭代升级性是指软件可通过OTA等技术实现远程迭代升级，从而改变产品使用模式以及整车开发模式，使汽车具有全周期生命力。

交互与评价的数据可采性是指能够采集用户交互与评价体系数据，实现用户分析，满足个性化定制需求。

5 结论

软件定义汽车是大势所趋，本文中分析提出软件定义汽车整车开发、整车物理结构和整车信息结构，并总结提出软件定义汽车技术体系。

在软件定义汽车技术体系中，软件定义汽车双闭环开发流程与并行开发模式深入渗透软硬件开发，使汽车成为具有生命力的产品，使整车开发在车辆全生命周期持续迭代进行，整车物理结构与整车信息结构实现有效解耦，整车功能的定义与实现主要通过软件驱动，整车物理结构不再与特定功能绑定，而是被抽象成可以被软件和服务共享的资源池，支撑软件多样化开发与部署，从而实现汽车由软件定义。

END

（内容来源：微信公众号“智能汽车设计”，2023.2.6，作者：孟天闯等）