《中国汽车基础软件发展报告 5.0》解读

导读:：本文节选自《中国汽车基础软件发展报告5.0》，本报告围绕汽车智能化发展趋势下的软件架构，探讨并关注如何在融入 AI 大模型的情况下，打造安全、可靠、稳定的开放式软件架构，以及该架构中的关键技术、实践案例与发展趋势，旨在为整车智能化软件产业链参与者提供有益的指导和参考。本报告分为8个章节，由软件架构、生态系统到未来发展趋势的预判。

本文节选第一章：面向 AI 大模型的开放式软件架构概述

01.开放式软件架构

开放式软件架构是指软件系统或应用程序基于开放的标准和接口进行设计和开发，可以与其他系统或应用程序进行无缝集成和交互，这种架构模式可以提高软件的灵活性、可扩展性和互操作性，同时也可以降低软件的成本和风险。其本质是：基于规则的开放参与共建软件架构，且规则本身对于全体参与者来说，也是开放可修改的。基于这一定义与原则，AUTOSEMO 从成立开始就提出了汽车软件架构，经过这几年演进，已从基础软件平台演化到 2023 年发布的整车软件开发平台（如图 1.1-1 整车软件开发平台所示）。

图1.1-1 整车软件开发平台

开放式软件架构具备三大特点：

（1）软件架构：以稳定性和安全性高的操作系统底座为基础，开放性强、兼容度高，复用性好的中间件为核心；

（2）工具链友好：包括 SDK（Software Development Kit，软件开发工具包，以下简称 SDK）、API（Application Programming Interface, 应用程序编程接口，以下简称 API）、文档等开发者工具，帮助开发者更快地开发和部署应用程序和服务；

（3）生态属性：行业共建，持续迭代，具有延续性和开放兼容性。

1. 开放式架构

开放式架构（Open Software Architecture，以下简称 OSA）作为一种创新的软件设计理念，为汽车软件领域带来了革命性的变革。它不仅从根本上加速了软件的迭代更新，还极大地丰富了功能扩展的可能性，并促进了跨领域的协同合作。在一个不断生长的开放式架构模式下，扩展性、适应性、可靠性、松耦合等能力，才是软件的核心竞争力。

图1.1-2 AUTOSEMO开放式软件架构详细

如图 1.1-2 所示，AUTOSEMO 的开放式软件架构基础软件部分，除操作系统内核之外，还有用于跨域交互的中间件 ASF（AUTOSEMO Service framework，AUTOSEMO 通用服务框架中间件，以下简称 ASF）。ASF 框架是面向整车跨域控制器打造的 SOA（Service-Oriented Architecture，面向服务的架构，以下简称 SOA）框架下的中间件，基于标准基础软件向上扩展，解决域控制器异构芯片跨核融合问题，实现域控制器的统一开发视图。ASF 框架是开放的分布式服务框架，通过 ASF 规范统一服务和接口定义，梳理服务开发环境与运行环境，用于打造高效、集成便捷的开发式架构。

2. 工具链

在汽车软件开放式架构中，开发者工具是连接软件开发者与系统硬件、中间件及最终应用的桥梁，也是保障系统有效开发和维护的关键。汽车电子电气架构趋于复杂化，在多域融合的架构中，满足开发者应用的工具显得尤为重要。这些工具不仅要支持不同领域的开发需求，还要提供统一的接口和标准，以确保系统各部分的高效集成，从提升开发效率，到确保软件质量，促进多域融合架构下软件的快速迭代与部署。

3. 生态属性

开放式架构需要从两个维度进行生态建设：一是技术维度，通过开源社区、开放标准、开发者技术平台等途径，促进开放式软件架构的推广应用和技术迭代。二是产业维度，通过构建分层解耦的生态系统，促进产业合理分工和投入，减少重复开发，提高资源利用率，推动整个产业的效率提升和技术创新。总结来看，开放式架构的生态建设具备如下能力：

（1）为行业开发者提供可复用的软件及工具，从而帮助降低开发和部署的成本，减少风险。

（2）提高互操作性和标准化程度，使得不同的技术可以更好地协同，支持在平台中进行快速迭代、原型开发和测试验证。

（3）有助于解决技术碎片化问题，通过共研共创，减少重复开发，提高资源利用率，推动整个产业的效率提升和技术创新。

（4）持续关注技术的最新发展，迅速找到上下游企业对同一种技术的开发难点与痛点。通过培训、研讨会等手段找到共同解决问题的思路，保持对新技术和发展趋势的了解，以应对汽车产业每一个重要的变革阶段。

02.AI 大模型

人工智能在汽车行业内的应用领域和场景非常广泛，从自动驾驶到车辆维护，从个性化用户体验到安全监控，从生产制造到销售售后，AI 技术正在重塑汽车行业的方方面面。AI 大模型则标志着 “人工智能”从量变走向质变，正以其强大的计算能力和学习能力深刻推动着汽车产业的进步。

1. AI 大模型分类

为了更好地理解大模型的应用背景和潜力，首先需要对大模型的分类有一个清晰的认识。根据处理数据类型的不同，大模型可以分为如下几类：

l 语言大模型：专注于处理和理解自然语言数据，能够执行文本生成、机器翻译、情感分析等任务。

l 视觉大模型：处理图像和视频数据，执行物体检测、图像分类、场景理解等视觉相关的任务。

l 多模态大模型：结合语言、视觉等多种类型的数据，实现跨模态的理解和生成，例如通过图像理解场景并生成描述文字。

根据应用领域不同，大模型可以分为如下几类：

l 通用大模型：设计用于广泛的应用场景，具有较高的灵活性和适应性，但可能在特定领域的专业性上不如垂直大模型。

l 行业大模型：针对特定行业的需求定制，具备较强的通用性和适应性，能够处理多种任务，相当于 AI 成为行业专家。

l 垂直大模型：专注于特定领域或细分市场，具备高专业性和针对性，通常在特定任务上表现更佳，如面向 ASPICE（Automotive Software Process Improvement and Capacity Determination，汽车软件过程改进及能力评估，以下简称 ASPICE）汽车软件架构的汽车软件编码大模型。

2. 汽车行业垂直大模型

如图 1.2-1 中国主流大模型应用选型评估矩阵所示，目前通用的大模型百花齐放，如 chatGPT、文心一言、通义千问、星火、智谱等，但针对汽车行业的垂直大模型仍然相对较少，主要原因如下：

图1.2-1 中国主流大模型应用选型评估矩阵

（1）高度专业化的需求：

汽车行业对软件的安全性、可靠性和实时性有着极高的要求。这些要求导致汽车软件的开发必须遵循严格的行业标准，如 ASPICE（汽车软件过程改进及能力评估）、ISO26262（道路车辆功能安全）、AUTOSAR（汽车开放系统架构）等。垂直大模型需要能够理解和适应这些标准，这增加了模型开发的复杂性。

（2）数据获取的高难度：

汽车行业涉及的数据类型多样，包括车辆动力学数据、传感器数据、控制算法等。这些数据往往受到严格管控，互通性低，且还需要在实际车辆上进行测试和验证，直接限制了可用于训练垂直大模型的数据量。

（3）技术和资源的密集性：

构建垂直大模型需要大量的计算资源和专业知识。与科技巨头相比，汽车领域的软件公司在计算资源、AI 专业人员、大模型开发与实施等方面上存在劣势。

（4）长开发周期和高成本：

汽车软件的开发周期通常较长，且成本较高。这使得企业在投资垂直大模型时更为谨慎，因为需要确保投资能够带来相应的回报。

（5）技术更新迭代快：

汽车行业的技术迭代速度非常快，新的传感器、控制单元和软件架构不断涌现。垂直大模型需要不断更新以适应这些变化，模型的迭代、升级和维护的代价高、难度大。

3. AI 端侧部署

当前，AI 在汽车领域开始积极应用。从早期的研发辅助、到辅助车型设计、供应链管理，AI 都极大地提升了工作效率。目前，随着各厂家对 AI 大模型的进一步研究使用，裁减后的 AI 大模型在端侧部署已成为新的技术趋势。从目前讨论较多的智驾端到端方案再到座舱领域的智慧化交互以及整车的智能体（AI Agent）方案，AI 大模型已开始与开放式软件架构进行融合。

03.面向 AI 大模型的开放式软件架构

结合工程中的优秀实践以及 AI 大模型的端侧部署方案，我们对之前提出的整车软件开发平台作了完善，形成了面向 AI 大模型的开放式软件架构。

1.3-1 面向AI大模型的开放式软件架构的定义与构成

面向 AI 大模型的开放式软件架构如图 1.3-1 所示。基于对开放式软件架构的分析，面向 AI 大模型的开放式软件架构除去上层应用之外可以分为操作系统、中间件、工具链以及生态四部分构成。应用主要分为车端应用和云端应用，将在第二章详细展开。软件架构基础软件部分自下而上，首先对整车服务框架规范 ASF 做更丰富的完善，以应对当前多域融合、数据处理以及 AI 部署的技术趋势；标准中间件部分，主要遵循 Classic platform AUTOSAR（以下简称 CP）以及 Adaptive platform AUTOSAR（以下简称AP）的标准定义；操作系统内核，聚焦在开放式架构下，如何平衡性能、安全和第三方生态；工具链部分，则融入多团队协作以及 AI 开发友好这一理念，进行迭代升级。

1. 开放式软件架构的中间件

图 1.3-2 面向AI大模型的开放式软件架构中间件构成

如图 1.3-2 所示，面向 AI 大模型的开放式软件架构主要由 ASF 中间件和标准中间件两部分构成。

 ASF 中间件：

l 对外的接口：给应用提供的 API（应用程序编程接口），需要支持本地，车内其他节点，云端的调用；

l 功能软件：应用软件加速器；

l AI 大模型 / 应用框架：车端的 AI 模型和基础类库；

l 整车数据处理框架：多域融合趋势下，提供整车数据处理单元，实现数据与逻辑的分离。支持AI 趋势下，对车端数据处理的要求；

l 整车通信总线：多域融合趋势下，提供整车统一的通信框架。包括针对整车不同架构的控制器、不同物理总线、不同通信协议、不同操作系统、不同开发语言及开发体系的统一通信接口及开发方法论。支持 AI 趋势下，对车端的通信要求；

l 车辆基础服务：车辆基础服务中间件在多域融合的架构下，可以将不同芯片、不同 ECU 甚至不同功能的资源进行协同处理和调用，并打通不同基础系统间的通信。车辆基础服务中间件在AUTOSAR 基础软件规范的基础上进行接口封装、特性增强和场景扩展，解决快速创新的问题；

l 标准中间件的接口抽象层：对标准中间件（CP AUTOSAR 和 AP AUTOSAR）的抽象。

 标准中间件：

l Classic Platform AUTOSAR：运行于 MCU（微控制器）或 SoC（System of Chip，片上系统）的 R 核，主要用于安全车控；

l Adaptive Platform AUTOSAR：运行于 SoC 的 A 核，主要用于支撑 SOA 架构下的服务，应用于智能驾驶和智能座舱以及服务网关等。

2. 开放式软件架构的操作系统底座

近些年有一些声音，意在形成统一的操作系统，即用一个内核支持车控、智驾和座舱这三种不同的应用需求。但当下尚未形成统一的技术路线，仍然是多种操作系统基于场景需求进行组合使用，可预见的未来技术路线仍然会多路并行。

l 智能车控：仍然以 Classic Platform AUTOSAR 作为主流方案。部分 Tier1 考虑 CP 本身过重、存在一定使用门槛、OS 调度方式过少等因素，一般基于 FreeRTOS（开源的小型实时操作系统）或其他实时操作系统，形成替代 CP 的车控解决方案。

l 智能驾驶：存在多条技术路线。部分厂家完全基于 Linux 进行算法调度和安全监控，或者基于QNX 等微内核方案实现智驾系统调度，也有厂家基于 Linux+RTOS 方案，尽可能地兼顾性能和安全需求。

l 智能座舱：座舱领域，主要基于 Andriod 进行车载影音娱乐模块的功能开发，此外在仪表等车控领域，则采用 CP 或微内核方案。

3. 开放式软件架构的工具链

开放式架构从根本上加速了软件的迭代更新，并极大地丰富了功能扩展的可能性，促进了跨领域协同合作。随着开放式软件架构的不断演进，新的汽车软件开发过程中需要引入敏捷开发模式、模块化设计、标准化接口、持续集成与持续部署、跨领域合作、安全管理、AI 赋能等新的开发理念。基于这些，除了《中国汽车基础软件发展白皮书 4.0》（以下简称：白皮书 4.0）中介绍的工具链之外，本报告中提出了高效开发框架，用于提升开发效率、支持多团队协作以及支持 AI 开发以及融合 AI 的新一代软件工程技术方案。

4. 开放式软件架构的生态建设

开放式软件架构的生态系统指的是技术生态和产业生态，技术生态主要包括接口统一、技术路线共识，这样有利于产业链上下游合理分工，化整为零，协作开发，促进技术创新；产业生态则是致力于建立开源开放的多层解耦的立体生态体系，有利于软件架构的演进和技术路线的聚焦发展，促进产业协同进步。

感谢以下单位对本报告的贡献：