定制报告-个性化定制-按需专项定制研究报告

行业报告、薪酬报告

联系：400-6363-638

《AUTOSEMO：2024中国汽车基础软件发展白皮书5.0（116页）.pdf》由会员分享，可在线阅读，更多相关《AUTOSEMO：2024中国汽车基础软件发展白皮书5.0（116页）.pdf（116页珍藏版）》请在本站上搜索。 1、指导单位：工业和信息化部装备工业发展中心发布单位：中国汽车工业协会软件分会中国汽车基础软件生态标委会（AUTOSEMO）中国汽车工业协会软件分会中国汽车基础软件生态标委会（AUTOSEMO）地址:北京市丰台区汽车博物馆东路诺德中心11号楼33层邮政编码：110160联系电话:010-63979900邮箱:autosemo-网址:中国汽车基础软件发展报告 5.0面向 AI 大模型的开放式软件架构序 言PREFACE全球汽车产业正面临着能源和智能两大方向转型，这给中国汽车产业带来了由大到强的发展机会。转型的上半场是能源转型，中国汽车产业在全球化竞争中占据了有利地位。与此同时，国内新能源汽车市场竞争2、也日趋激烈，价格战持续不断。面对竞争更加激烈的下半场，各整车厂虽通过以价换市、加速车型迭代等手段积极应对，但根源上需要抓紧这一轮人工智能等新技术，形成产业革新的有效破局举措。扎根基础技术，需要所有从业者平心静气、耐得住寂寞，在高质量发展的指引下，稳步推进产品技术迭代，助力国家迈进汽车强国。智能化是汽车产业转型下半场的核心，软件则是智能化的关键，是构建差异化的整车应用和创新汽车业务的核心驱动力。目前，各厂家拼杀愈加激烈，加上市场对自动驾驶、智能座舱和万物互联等个性化需求的快速增长，导致厂家车型迭代、软件开发和集成验证的复杂度大幅增加，开发成本居高不下。这里提出一个想法如果行业内构建出开放性的软件3、架构作为基础，使得其他应用或扩展都能在这个基础上柔性生长，是否可以解决当前行业问题。对于基础的构建，可以参考乐高模式，即立足模块化设计理念，通过组合标准部件，实现多样化创新。这种通用的行业标准、工具和方法，可以大幅提高开发效率，保证产品质量的稳定性，为厂家赢得时间和资源上的双重优势。另外，引爆本轮技术革新的核心人工智能技术正凭借其强大的数据处理、自我学习和主动生成等能力，颠覆整个汽车智能化的发展节奏和开发模式，使汽车软件创新开发的新范式、新思路也层出不穷。在开放式软件架构中，也需要深度融入、挖掘人工智能的能力，为汽车智能化的革新性发展筑牢基础。国产汽车基础软件方面，开放式软件架构模式近些年发展4、迅猛，其产品力和质量均有较大提升，市场占有率也持续提高。当然，发展过程中也暴露了产品迭代频繁、研发效率低成本高、行业低水平内卷、商业模式无法闭环等问题。为了在全球汽车产业智能化乃至生态化的竞争中抢占战略制高点，增强中国的汽车软件实力，AUTOSEMO 联合主机厂、Tier1、软件、芯片厂商和高校科研院所，编制了中国汽车基础软件发展报告 5.0，该报告围绕汽车智能化发展趋势下的软件架构，探讨如何在融入 AI 大模型的情况下，打造安全、可靠、稳定的开放式软件架构，希望可以给整车智能化软件产业链参与者提供有益参考和帮助。2024 年 10 月 13 日中国汽车基础软件发展白皮书 5.0I一、面向 A5、I 大模型的开放式软件架构概述001(一)开放式软件架构0021.开放式架构 0022.工具链 0033.生态属性 003(二)AI 大模型0041.AI 大模型分类 0042.汽车行业垂直大模型 0043.AI 端侧部署 006(三)面向 AI 大模型的开放式软件架构 0061.开放式软件架构的中间件 0072.开放式软件架构的操作系统底座 0073.开放式软件架构的工具链 0084.开放式软件架构的生态建设 008二、开放式软件架构的应用层009(一)车端应用0091应用场景 0092AI 大模型在车端应用的挑战 0143AI 大模型在车端应用的演化趋势 015(二)云端应用0151应用场6、景 0152AI 大模型在云端应用的挑战 0183AI 大模型在云端应用的演化趋势 018CONTENTS目录中国汽车基础软件发展白皮书 5.0II三、开放式软件架构的中间件层020（一）开放式软件架构的中间件 0201.面向 MCU 的标准基础软件 0212.面向 SoC 的标准基础软件0233.车辆基础服务 0244.整车通信总线 0325.整车数据处理框架 039（二）AI 大模型与中间件 0441.AI 大模型技术对中间件的影响 0442.基于大模型的中间件 0453.AIAgent 基础服务层 0454.AI 大模型与中间件结合的发展趋势 046四、开放式软件架构的操作系统底座0477、（一）开放式软件架构下的操作系统 0471软硬一体 0472虚拟化 0493实时操作系统 0554SafetyLinux058（二）开放架构下的操作系统安全 0621.信息安全 0632.功能安全 065（三）人工智能与操作系统 0661.AIforOS 0662.OSforAI 0663.AIasOS 068五、开放式软件架构的工具链071（一）经典工具链 0711.面向MCU的标准基础软件的开发者工具 0712.面向SOC的标准基础软件的开发者工具 072中国汽车基础软件发展白皮书 5.0III3.车辆基础服务的开发者工具 0734.整车通信总线的开发者工具 074（二）开放的高效开发框架8、 0751.高效开发框架的定义 0762.高效开发框架的功能 0773.高效开发框架的接口参考 0784.高效开发框架的开发方法 079（三）AI 大模型赋能创新工具链 0801.软件工程变革 0802.软件需求开发 0823.软件架构开发 0834.软件代码开发 0845.软件测试 087六、开放式软件架构的生态建设088（一）技术生态 0881.开放式接口的统一 0882.通信协议的统一 0893.开发标准和流程的统一 0904.开源库在汽车开发中的重要性 090（二）产业生态 0911.当前的问题与挑战 0912.破局之道的思考 092七、AI 大模型对整车软件发展趋势和技术路线的影响09、93（一）发展趋势 0931.算法、算料、算力与场景 0932.整车软件开发方法的变革 095（二）技术路线 0961.基于大模型的新型软件工艺 0962.整车软件技术的演进方向 0993.趋势下的技术点 099中国汽车基础软件发展白皮书 5.0IV（三）AI 大模型应用落地方法 100八、案例介绍102（一）软件平台 102（二）中间件 102（三）操作系统 103（四）信息安全 104（五）工具链 105主要贡献单位107中国汽车基础软件发展白皮书 5.0001一、面向AI大模型的开放式软件架构概述近年来，人工智能技术的发展进入新阶段，大模型在各行各业掀起了智能化变革浪潮。在汽车领域，AI10、（ArtificialIntelligence 人工智能，以下简称 AI）的技术驱动能力完美契合了当下汽车的发展需求，作为新一代智能终端，汽车的智能化发展目前有两大趋势：一是电子电气架构的中央集中，舱驾控三域融合甚至五域（智能座舱、智能驾驶、车身控制、底盘控制与动力控制）融合的中央计算平台已处于预研或上车阶段其中复杂的域融合，给整个汽车软件的研发效率、质量、扩展性和延续性等带来了诸多挑战，亟需开放式的软件架构支撑。二是 AI 大模型加速应用，一方面通过对软件工程等辅助开发，提升研发效率和质量；另外一方面则通过在自动驾驶、智能座舱等控制器的端侧部署，为用户带来全新体验，这些也对目前的软件架构带来11、了新的挑战。本报告围绕汽车智能化发展趋势下的软件架构，探讨并关注如何在融入 AI 大模型的情况下，打造安全、可靠、稳定的开放式软件架构，以及该架构中的关键技术、实践案例与发展趋势，旨在为整车智能化软件产业链参与者提供有益的指导和参考。报告中各章节核心阐述内容如下：第一章面向 AI 大模型的开放式软件架构概述：介绍了 AUTOSEMO（中国汽车工业协会软件分会中国汽车基础软件生态标委会，以下简称 AUTOSEMO）的开放式软件架构，阐述 AI 大模型的发展已可以深度融入开放式架构并对其发展起到促进作用，从而形成面向 AI 大模型的开放式软件架构这一持续迭代发展的架构方案。第二章开放式软件架构的应12、用层：主要介绍了 AI 大模型在当前汽车智能化应用中的发展情况、挑战和技术趋势。第三章开放式软件架构的中间件层：主要介绍了开放式架构下的中间件，包含标准中间件、车辆基础服务、整车通信总线和整车数据处理框架以及 AI 大模型与中间件的结合。第四章开放式软件架构的操作系统底座：结合应用场景，介绍开放式软件架构下的操作系统如虚拟化、SafetyLinux（功能安全 Linux 操作系统）和实时操作系统的技术重点和演进趋势；同时聚焦开放式软件架构下的操作系统安全问题，如信息和功能安全问题及演化趋势；其次，聚焦 AIOS（人工智能操作系统）这一全新概念，探讨当前发展现状和未来趋势。第五章开放式软件架构的13、工具链：探讨多域融合背景下，通用的汽车电子研发工具链以及用于解决如何更好地多方协同、提升开发效率和质量，同时支持 AI 扩展的高效开发框架。最后介绍应用于整个汽车软件工程的 AI 大模型工具链。第六章开放式软件架构的生态建设：从技术生态和产业生态两个维度，分析如何通过行业共建，构建技术标准和开发流程、建设开源库、保证可持续发展；此外通过构建分层解耦的协作关系，确保行业各层级可以各司其职、正向迭代发展。第七章AI 大模型对整车软件发展趋势和技术路线的影响：对汽车行业深度融合 AI 大模型所带来的变化进行深入分析，引出对行业趋势和技术路线的思考，继而探讨大模型应用的落地方法。第八章行业内多家企业的14、实践方案的分享。中国汽车基础软件发展白皮书 5.0002(一)开放式软件架构开放式软件架构是指软件系统或应用程序基于开放的标准和接口进行设计和开发，可以与其他系统或应用程序进行无缝集成和交互，这种架构模式可以提高软件的灵活性、可扩展性和互操作性，同时也可以降低软件的成本和风险。其本质是：基于规则的开放参与共建软件架构，且规则本身对于全体参与者来说，也是开放可修改的。基于这一定义与原则，AUTOSEMO 从成立开始就提出了汽车软件架构，经过这几年演进，已从基础软件平台演化到 2023 年发布的整车软件开发平台（如图 1.1-1 整车软件开发平台所示）。图1.1-1 整车软件开发平台开放式软件架构15、具备三大特点：（1）软件架构：以稳定性和安全性高的操作系统底座为基础，开放性强、兼容度高，复用性好的中间件为核心；（2）工具链友好：包括 SDK（SoftwareDevelopmentKit，软件开发工具包，以下简称 SDK）、API（ApplicationProgrammingInterface,应用程序编程接口，以下简称 API）、文档等开发者工具，帮助开发者更快地开发和部署应用程序和服务；（3）生态属性：行业共建，持续迭代，具有延续性和开放兼容性。1.开放式架构开放式架构（OpenSoftwareArchitecture，以下简称 OSA）作为一种创新的软件设计理念，为汽车软件领域带来了16、革命性的变革。它不仅从根本上加速了软件的迭代更新，还极大地丰富了功能扩展的可能性，并促进了跨领域的协同合作。在一个不断生长的开放式架构模式下，扩展性、适应性、可靠性、松耦合等能力，才是软件的核心竞争力。硬件标准规范工具链（开发、仿真、调试、测试等）Adaptive AUTOSARClassic AUTOSAR操作系统内核OS虚拟化Hypervisor功能软件面向服务的ASF框架数据中心云端设备AIOT设备平台服务中间件操作系统车端应用云端应用AIOT生态应用整车软件开发平台车端平台云端平台AIOT端平台中国汽车基础软件发展白皮书 5.0003图1.1-2 AUTOSEMO开放式软件架构详细如图17、 1.1-2 所示，AUTOSEMO 的开放式软件架构基础软件部分，除操作系统内核之外，还有用于跨域交互的中间件 ASF（AUTOSEMOServiceFramework，AUTOSEMO 通用服务框架中间件，以下简称ASF）。ASF框架是面向整车跨域控制器打造的SOA（Service-OrientedArchitecture，面向服务的架构，以下简称 SOA）框架下的中间件，基于标准基础软件向上扩展，解决域控制器异构芯片跨核融合问题，实现域控制器的统一开发视图。ASF 框架是开放的分布式服务框架，通过 ASF 规范统一服务和接口定义，梳理服务开发环境与运行环境，用于打造高效、集成便捷的开发式18、架构。2.工具链在汽车软件开放式架构中，开发者工具是连接软件开发者与系统硬件、中间件及最终应用的桥梁，也是保障系统有效开发和维护的关键。汽车电子电气架构趋于复杂化，在多域融合的架构中，满足开发者应用的工具显得尤为重要。这些工具不仅要支持不同领域的开发需求，还要提供统一的接口和标准，以确保系统各部分的高效集成，从提升开发效率，到确保软件质量，促进多域融合架构下软件的快速迭代与部署。3.生态属性开放式架构需要从两个维度进行生态建设：一是技术维度，通过开源社区、开放标准、开发者技术平台等途径，促进开放式软件架构的推广应用和技术迭代。二是产业维度，通过构建分层解耦的生态系统，促进产业合理分工和投入，减19、少重复开发，提高资源利用率，推动整个产业的效率提升和技术创新。总中国汽车基础软件发展白皮书 5.0004结来看，开放式架构的生态建设具备如下能力：（1）为行业开发者提供可复用的软件及工具，从而帮助降低开发和部署的成本，减少风险。（2）提高互操作性和标准化程度，使得不同的技术可以更好地协同，支持在平台中进行快速迭代、原型开发和测试验证。（3）有助于解决技术碎片化问题，通过共研共创，减少重复开发，提高资源利用率，推动整个产业的效率提升和技术创新。（4）持续关注技术的最新发展，迅速找到上下游企业对同一种技术的开发难点与痛点。通过培训、研讨会等手段找到共同解决问题的思路，保持对新技术和发展趋势的了解，20、以应对汽车产业每一个重要的变革阶段。(二)AI 大模型人工智能在汽车行业内的应用领域和场景非常广泛，从自动驾驶到车辆维护，从个性化用户体验到安全监控，从生产制造到销售售后，AI 技术正在重塑汽车行业的方方面面。AI 大模型则标志着“人工智能”从量变走向质变，正以其强大的计算能力和学习能力深刻推动着汽车产业的进步。1.AI 大模型分类为了更好地理解大模型的应用背景和潜力，首先需要对大模型的分类有一个清晰的认识。根据处理数据类型的不同，大模型可以分为如下几类：l 语言大模型：专注于处理和理解自然语言数据，能够执行文本生成、机器翻译、情感分析等任务。l 视觉大模型：处理图像和视频数据，执行物体检测、21、图像分类、场景理解等视觉相关的任务。l 多模态大模型：结合语言、视觉等多种类型的数据，实现跨模态的理解和生成，例如通过图像理解场景并生成描述文字。根据应用领域不同，大模型可以分为如下几类：l 通用大模型：设计用于广泛的应用场景，具有较高的灵活性和适应性，但可能在特定领域的专业性上不如垂直大模型。l 行业大模型：针对特定行业的需求定制，具备较强的通用性和适应性，能够处理多种任务，相当于 AI 成为行业专家。l 垂直大模型：专注于特定领域或细分市场，具备高专业性和针对性，通常在特定任务上表现更佳，如面向 ASPICE（AutomotiveSoftwareProcessImprovementandC22、apacityDetermination，汽车软件过程改进及能力评估，以下简称 ASPICE）汽车软件架构的汽车软件编码大模型。2.汽车行业垂直大模型如图 1.2-1 中国主流大模型应用选型评估矩阵所示，目前通用的大模型百花齐放，如 chatGPT、文心一言、通义千问、星火、智谱等，但针对汽车行业的垂直大模型仍然相对较少，主要原因如下：中国汽车基础软件发展白皮书 5.0005图1.2-1 中国主流大模型应用选型评估矩阵（1）高度专业化的需求：汽车行业对软件的安全性、可靠性和实时性有着极高的要求。这些要求导致汽车软件的开发必须遵循严格的行业标准，如 ASPICE（汽车软件过程改进及能力评估）、I23、SO26262（道路车辆功能安全）、AU-TOSAR（汽车开放系统架构）等。垂直大模型需要能够理解和适应这些标准，这增加了模型开发的复杂性。（2）数据获取的高难度：汽车行业涉及的数据类型多样，包括车辆动力学数据、传感器数据、控制算法等。这些数据往往受到严格管控，互通性低，且还需要在实际车辆上进行测试和验证，直接限制了可用于训练垂直大模型的数据量。（3）技术和资源的密集性：构建垂直大模型需要大量的计算资源和专业知识。与科技巨头相比，汽车领域的软件公司在计算资源、AI 专业人员、大模型开发与实施等方面上存在劣势。（4）长开发周期和高成本：汽车软件的开发周期通常较长，且成本较高。这使得企业在投资垂直24、大模型时更为谨慎，因为需要确保投资能够带来相应的回报。（5）技术更新迭代快：汽车行业的技术迭代速度非常快，新的传感器、控制单元和软件架构不断涌现。垂直大模型需要不断更新以适应这些变化，模型的迭代、升级和维护的代价高、难度大。中国汽车基础软件发展白皮书 5.00063.AI 端侧部署当前，AI 在汽车领域开始积极应用。从早期的研发辅助、到辅助车型设计、供应链管理，AI 都极大的提升了工作效率。目前，随着各厂家对 AI 大模型的进一步研究使用，裁减后的 AI 大模型在端侧部署已成为新的技术趋势。从目前讨论较多的智驾端到端方案再到座舱领域的智慧化交互以及整车的智能体（AIAgent）方案，AI 大模25、型已开始与开放式软件架构进行融合。(三)面向 AI 大模型的开放式软件架构结合工程中的优秀实践以及 AI 大模型的端侧部署方案，我们对之前提出的整车软件开发平台作了完善，形成了面向 AI 大模型的开放式软件架构。1.3-1 面向AI大模型的开放式软件架构的定义与构成面向 AI 大模型的开放式软件架构如图 1.3-1 所示。基于对开放式软件架构的分析，面向 AI 大模型的开放式软件架构除去上层应用之外可以分为操作系统、中间件、工具链以及生态四部分构成。应用主要分为车端应用和云端应用，将在第二章详细展开。软件架构基础软件部分自下而上，首先对整车服务框架规范 ASF 做更丰富的完善，以应对当前多域融26、合、数据处理以及 AI 部署的技术趋势；标准中间件部分，中国汽车基础软件发展白皮书 5.0007主要遵循 ClassicplatformAUTOSAR（以下简称 CP）以及 AdaptiveplatformAUTOSAR（以下简称AP）的标准定义；操作系统内核，聚焦在开放式架构下，如何平衡性能、安全和第三方生态；工具链部分，则融入多团队协作以及 AI 开发友好这一理念，进行迭代升级。1.开放式软件架构的中间件图 1.3-2 面向AI大模型的开放式软件架构中间件构成如图 1.3-2 所示，面向 AI 大模型的开放式软件架构主要由 ASF 中间件和标准中间件两部分构成。ASF 中间件：l 对外的接27、口：给应用提供的 API（应用程序编程接口），需要支持本地，车内其他节点，云端的调用；l 功能软件：应用软件加速器；l AI 大模型/应用框架：车端的 AI 模型和基础类库；l 整车数据处理框架：多域融合趋势下，提供整车数据处理单元，实现数据与逻辑的分离。支持AI 趋势下，对车端数据处理的要求；l 整车通信总线：多域融合趋势下，提供整车统一的通信框架。包括针对整车不同架构的控制器、不同物理总线、不同通信协议、不同操作系统、不同开发语言及开发体系的统一通信接口及开发方法论。支持 AI 趋势下，对车端的通信要求；l 车辆基础服务：车辆基础服务中间件在多域融合的架构下，可以将不同芯片、不同 ECU 28、甚至不同功能的资源进行协同处理和调用，并打通不同基础系统间的通信。车辆基础服务中间件在AUTOSAR 基础软件规范的基础上进行接口封装、特性增强和场景扩展，解决快速创新的问题；l 标准中间件的接口抽象层：对标准中间件（CPAUTOSAR 和 APAUTOSAR）的抽象。标准中间件：l ClassicPlatformAUTOSAR：运行于 MCU（微控制器）或 SoC（SystemofChip，片上系统）的 R 核，主要用于安全车控；l AdaptivePlatformAUTOSAR：运行于 SoC 的 A 核，主要用于支撑 SOA 架构下的服务，应用于智能驾驶和智能座舱以及服务网关等。2.开放29、式软件架构的操作系统底座近些年有一些声音，意在形成统一的操作系统，即用一个内核支持车控、智驾和座舱这三种不同的应中国汽车基础软件发展白皮书 5.0008用需求。但当下尚未形成统一的技术路线，仍然是多种操作系统基于场景需求进行组合使用，可预见的未来技术路线仍然会多路并行。l 智能车控：仍然以 ClassicPlatformAUTOSAR 作为主流方案。部分 Tier1 考虑 CP 本身过重、存在一定使用门槛、OS 调度方式过少等因素，一般基于 FreeRTOS（开源的小型实时操作系统）或其他实时操作系统，形成替代 CP 的车控解决方案。l 智能驾驶：存在多条技术路线。部分厂家完全基于 Linux30、 进行算法调度和安全监控，或者基于QNX 等微内核方案实现智驾系统调度，也有厂家基于 Linux+RTOS 方案，尽可能地兼顾性能和安全需求。l 智能座舱：座舱领域，主要基于 Andriod 进行车载影音娱乐模块的功能开发，此外在仪表等车控领域，则采用 CP或微内核方案。3.开放式软件架构的工具链开放式架构从根本上加速了软件的迭代更新，并极大地丰富了功能扩展的可能性，促进了跨领域协同合作。随着开放式软件架构的不断演进，新的汽车软件开发过程中需要引入敏捷开发模式、模块化设计、标准化接口、持续集成与持续部署、跨领域合作、安全管理、AI 赋能等新的开发理念。基于这些，除了中国汽车基础软件发展白皮书 31、4.0（以下简称：白皮书 4.0）中介绍的工具链之外，本报告中提出了高效开发框架，用于提升开发效率、支持多团队协作以及支持 AI 开发以及融合 AI 的新一代软件工程技术方案。4.开放式软件架构的生态建设开放式软件架构的生态系统指的是技术生态和产业生态，技术生态主要包括接口统一、技术路线共识，这样有利于产业链上下游合理分工，化整为零，协作开发，促进技术创新；产业生态则是致力于建立开源开放的多层解耦的立体生态体系，有利于软件架构的演进和技术路线的聚焦发展，促进产业协同进步。中国汽车基础软件发展白皮书 5.0009二、开放式软件架构的应用层AI 大模型颠覆了以往基于规则进行算法开发的模式，转化为基32、于数据驱动的新范式。本章节结合应用场景将详细探讨相关的技术路线、挑战与演化趋势，旨在为读者带来一些启发。(一)车端应用1 应用场景1.1 智能座舱应用智能座舱系统的特点体现为高算力、中实时（毫秒级）、与车辆行驶安全弱相关，但有强人机交互需求这几方面。其设备端主要包括中控大屏、数字仪表、流媒体后视镜、HUD（车辆平视显示系统）、行车记录仪等。AI 大模型在智能座舱中的应用，不仅能够增强人机交互的自然性和便捷性，还能够提供更加个性化的服务，驱动着座舱系统由智能体进化至智慧体。以下是AI大模型在智能座舱中的几个典型应用场景：（1）多模态交互AI 大模型可以作为智能座舱中语音识别和自然语言处理的核心，33、使车辆能够理解和响应驾驶员及乘客的语音指令。此外，它还可以结合情境感知，实时分析车外环境信息，比如天气和交通状况，为用户提供智能助手功能，增强交互体验。（2）个性化智能推荐利用 AI 大模型对用户行为和偏好的学习，智能座舱可以提供个性化的服务和内容推荐。例如，根据用户的驾驶习惯和常用路线，推荐最优的行车路线；或者根据用户的音乐播放历史，推荐用户可能喜欢的歌曲。同时，系统可以与智能家居联动，在接近家时自动调整家中环境，提升整体生活便利性。（3）驾驶员行为分析AI 大模型可以通过分析驾驶员的操作习惯、生理状态（如面部表情、心率等）和驾驶行为，根据综合分析调整车内环境，以提升驾乘体验。此外，可以识别34、驾驶员的情绪状态，当检测到紧张或焦虑时，系统能够自动播放放松音乐，或根据驾驶员的状态分析，检测疲劳驾驶等情况，从而提高驾驶的安全性。1.2 智能驾驶应用智能驾驶系统的特点体现为高算力、高实时性（毫秒级，确定时间范围内）、与车辆行驶安全强相关。（1）传统算法在智驾的传统顺序方法感知、决策和规控中，AI 大模型应用情况如下：l 环境感知AI 大模型通过车载传感器（如摄像头、雷达、激光雷达等）获取车辆周围的环境信息，并对这些信息进行分析和处理，进行周围环境的实时感知，为自动驾驶提供基础数据支持。l 决策规划决策规划环节中，AI 大模型可以根据环境感知获得的信息，结合车辆的状态，制定出最优的行驶策略。35、即使遇到复杂的交通情况，AI 大模型也能够快速做出合理的决策，提高驾驶的安全性和舒适性。l 控制执行中国汽车基础软件发展白皮书 5.0010AI 大模型可以将决策规划转化为具体的控制指令，控制车辆的加速、减速、转向等操作。通过对车辆动力学模型的学习，AI 大模型可以实现精准的控制执行，提高车辆的操控性能和稳定性。如今在智能驾驶领域，端到端解决方案正逐渐成为主流，这里对端到端技术做详细分析：（2）端到端大模型算法如图 2.1-1 端到端模型所示，端到端是指：一端输入传感器数据（例如视频、激光雷达点云等信息），另一端直接输出驾驶决策（例如驾驶动作、驾驶轨迹等）的技术范式。图2.1-1 端到端模型传36、统的非端到端算法将任务进行切分，定义多个子任务：地图、定位、感知、预测、决策、规划、控制等子任务负责解决驾驶过程的某些特定问题，这些任务独立开发、独立测试，最终集成到一起完成自动驾驶任务。相比于传统的自动驾驶方案，端到端方案的训练方式能够实现系统的全局最优，使得系统能够获得更好的驾驶效果；避免预设大量的人工规则，系统也更加简洁、模块简单、效率更高；通过数据驱动的方式，不断提升系统上限。1)端到端算法的实现方法模块化端到端：如图 2.1-2 模块化端到端所示，模块化端到端方法是将自动驾驶任务分解成若干个子任务，如感知、定位、路径规划和控制等，并针对每个子任务开发专门的算法或模型。这些模块通常是独37、立训练，在实际部署时连接起来作为完整系统运行。将传统自动驾驶的多个模块连接后进行端到端训练，如 Hydra-MDP（教师-学生知识蒸馏架构）包括感知网络、轨迹解码、Multi-targetHydra-Distillation（多目标知识蒸馏），三个部分进行端到端训练。这种方法的优点在于每个模块可以单独优化和测试，使得系统整体稳定可靠。缺点则是模块间的交互复杂，需要大量工程活动来确保模块间的协调一致。图2.1-2 模块化端到端中国汽车基础软件发展白皮书 5.0011单一网络端到端：如图 2.1-3 单一网络端到端所示，单一网络端到端方法完全摒弃传统自动驾驶方案的感知、预测、规划等思想，将所有的功38、能集成到一个深度神经网络中，该网络直接从传感器输入映射到车辆控制信号。这种方法不需要显式的中间步骤，直接通过大量数据训练得到一个能够直接完成从感知到动作的模型。单一网络端到端的优点在于其简化系统结构，减少中间环节，使得系统更易于训练和部署。缺点则是对数据量和多样性要求较高，由于缺乏明确的功能模块划分，难以对特定部分进行调试和优化。图2.1-3 单一网络端到端2)基于大模型的端到端自动驾驶端到端强调的是从输入到输出的端到端训练方式，追求系统全局最优。大模型优势在于模型的参数规模，以 GPT 为代表的大模型技术在自然语言处理方面表现出非常强大的泛化能力。端到端自动驾驶结合大模型，借助大模型强大的泛39、化能力来解决层出不穷的 cornercase（极端情况），借助海量的人驾数据，通过端到端学习来解决实现类人驾驶。端到端与大模型结合目前主要有三种方式：使用大模型直接开车，使用大模型来加速端到端的训练以及使用大模型来生成数据供自动驾驶训练。使用大模型直接开车：如图 2.1-4 使用大模型直接开车方案所示，大模型被训练成为能够直接从输入数据（如摄像头图像、雷达数据等）映射到输出控制指令（如转向角度、油门踏板位置等）的系统。大模型通常是具有强大泛化能力的预训练深度学习模型。这样不需要显式的中间步骤，提高实时性能。VLA 大模型(Vision-Lan-guage-Actionmodel，视觉语言模型)40、通过视觉编码器对视频进行编码并 token（AI 处理的数据或文本的最小单位）化，与文本和 query（学到的嵌入表示）一起输入 VLA 大模型中，即可输出驾驶动作，实现端到端自动驾驶。中国汽车基础软件发展白皮书 5.0012图2.1-4 使用大模型直接开车方案预训练大模型加速端到端自动驾驶：如图 2.1-5 预训练大模型所示，训练大模型都需要海量的数据，如让自动驾驶模型学会看懂警察手势、理解各类路牌、处理各类障碍物，需要海量的自动驾驶领域数据进行训练，仅仅依靠自动驾驶领域数据，其采集、存储、训练的成本都非常高。引入两个预训练大模型，利用其海量数据与通用能力，来帮助自动驾驶理解各类复杂场景，是41、目前最具性价比的降本方案。在感知阶段，通过多模态大模型对齐视觉特征与文本特征，实现识别万物；在驾驶决策阶段，通过引入预训练模型对驾驶场景做出解释和建议，提升学习效果。图2.1-5 预训练大模型大模型生成数据供自动驾驶训练：端到端自动驾驶训练的多样数据如果全部依赖实车采集，训练成本高。如图 2.1-6 大模型生成训练数据所示，使用大模型生成数据供自动驾驶训练是另外一种替代方案。世界模型（Worldmodel）被认为是大模型生成训练数据最有可能的方式之一。世界模型是能够对环境或世界的状态进行表征，并基于驾中国汽车基础软件发展白皮书 5.0013驶动作预测未来世界的模型。世界模型首先将当前世界看到的42、视频进行编码，结合驾驶动作和其他信息，进行 token（最小的语义单元）化，然后使用自回归的方式生成未来世界的 token，并解码成未来世界的视频。世界模型基于输入 action（动作）来生成对应的视频，按照特定的需求来人为构造对应的 action，生成数据，尤其对一些常规方法难以采集、非常危险的动作，如急刹、近距离切入等非常有效。图2.1-6 大模型生成训练数据1.3 智能车控应用智能车控包括动力系统、底盘系统、车身系统、电池管理系统、网联控车系统等，其特点体现为高安全、低算力、强实时（微秒级）、与车辆安全行驶强相关。由于车控系统本身对安全的高要求，AI 在车控系统的应用主要还在探索阶段。（43、1）动力系统优化AI 大模型可以根据车辆的实时数据，如发动机转速、负荷、温度等，优化动力系统的控制策略，提高燃油效率和性能。（2）电池管理系统（BMS）在电动汽车中，AI 大模型可以用于预测电池的健康状况、剩余电量和充电需求，从而优化电池的使用和维护策略，提升续航里程。（3）底盘控制系统AI 大模型可以集成到车辆的底盘控制系统中，实现自适应悬挂调节、电子稳定控制等，以提供更平稳和安全的驾驶体验。（4）车身电子系统AI 大模型可以用于控制车身电子系统，如自动调节车内温度、照明、车窗和车门锁等，以适应驾驶员和乘客的需求。（5）网联控车系统AI 大模型可以分析车辆的网络数据，实现远程监控、故障诊断和44、车辆优化，同时提供车辆与外部环境的智能交互。（6）车辆能源与热管理热管理需要考虑发动机、电池、电机等多个部件工作温度及其相互影响；系统设计和优化涉及多个学科，设计复杂性高；需要保证在各种环境条件下都能正常工作，系统可靠性要求高；提高车辆能量利用效率，中国汽车基础软件发展白皮书 5.0014延长续航里程，电池健康状态的监测与维护，延长电池使用寿命。通过大模型模拟不同工况下的热管理效果，帮助工程师优化设计方案，减少实际测试次数；利用大模型根据不同车型和使用场景，定制化热管理策略，最大化能效比。2 AI 大模型在车端应用的挑战2.1 技术挑战AI大模型通常需要大量的计算资源进行训练和推理。在车端应用45、中，如何满足 AI 大模型的计算资源需求是一个难题。需要开发高效的计算架构和算法，提高计算资源的利用率，降低计算成本。(1)计算资源需求高大模型通常具有庞大的参数量和复杂的计算结构，在车端部署大模型，同样需要大量的计算资源。车辆的嵌入式系统往往计算能力有限，难以满足大模型的运行要求。例如，进行实时的图像识别和处理、路径规划等任务时，可能会出现计算延迟，影响车辆的响应速度和安全性。为了解决这个问题，需要进行模型压缩和优化，以降低计算需求。同时，也需要开发更高效的硬件加速器，如专用的更高算力的 AI 芯片，来提升车端的计算能力。(2)数据处理与存储车端应用需要处理大量的传感器数据，包括摄像头图像、46、雷达数据、GPS信息等。AI 大模型对数据的质量和数量要求很高，如何高效地采集、传输、存储和处理这些数据是一个挑战。数据传输可能会受到网络带宽和稳定性的限制，特别是在车辆高速行驶或处于信号较弱的区域。此外，数据存储也需要考虑车辆有限的存储空间和数据安全问题。可以采用边缘计算和分布式存储等技术，在车端进行部分数据处理，减少对云端的依赖，提高数据处理的效率和实时性。同时，加强数据加密和安全防护措施，确保车辆数据的安全。(3)模型稳定性与可靠性车辆运行环境复杂多变，对 AI 大模型的可靠性和稳定性要求极高。在不同的天气条件、路况和驾驶场景下，模型需要始终保持准确和可靠的性能。例如，在恶劣的天气下，传47、感器数据可能会受到干扰，影响模型的判断。此外，模型还需要具备一定的容错能力，能够在部分传感器故障或数据异常的情况下继续正常工作。可以通过大量的实际测试和验证，不断优化模型的性能和鲁棒性。同时，建立备份和冗余机制，确保在出现问题时能够及时切换到备用系统，保障车辆的安全运行。2.2 安全挑战(1)功能安全AI 大模型在车端的应用直接关系到车辆的行驶安全。如果模型出现错误判断或决策失误，可能会导致严重的交通事故。因此，确保模型的功能安全是至关重要的。需要建立严格的安全标准和测试流程，对模型的性能、可靠性和安全性进行全面评估。同时，采用多种安全机制，如冗余设计、故障检测和隔离等，提高系统的安全性。例如48、，在自动驾驶系统中，可以采用多传感器融合和备份决策系统，以降低单一传感器或模型故障的风险。(2)网络安全智能化和网联化程度的提高，让车端正面临着越来越多的网络安全威胁。黑客可能会通过网络攻击入侵车辆系统，篡改AI 大模型的参数导致异常控制车辆的行为。加强车辆的网络安全防护，采用加密技术、身份认证和访问控制等措施，防止未经授权的访问和攻击。中国汽车基础软件发展白皮书 5.0015同时，建立实时的网络安全监测和响应机制，及时发现和应对网络安全事件。例如，对车辆的通信系统进行加密，确保数据传输的安全。对车载软件进行定期更新和漏洞修复，提高系统的安全性。车端网络安全入侵监测防御系统（Intrusion49、DetectionandPreventionSystem,以下简称：IDPS）在智能汽车和车联网环境中承担着发现并阻止网络攻击的任务。当前的 IDPS 基本还是依赖于基于规则的检测方法，这导致其在面对未知威胁和复杂攻击时容易出现漏报和漏检问题。AI 和机器学习技术在威胁检测中有很大潜力，机器学习模型能够通过学习大量历史数据，自动识别正常与异常的网络行为模式。当新的威胁出现时，系统可以通过持续学习和模型更新，逐步适应新的攻击手法；通过对正常行为模式的深入学习，基于机器学习的 IDPS 能够更准确地区分正常行为与异常行为，从而减少误报率。然而机器学习也面临着一些挑战，首先是训练数据的质量和数量问题50、，机器学习模型的性能高度依赖于训练数据。数据集的多样性和质量决定了模型的检测效果。如果训练数据不足或偏向，可能会导致模型无法有效识别攻击和异常；机器学习的资源需求问题，复杂的机器学习模型，尤其是深度学习模型，通常需要较高的计算资源和内存，这在资源有限的车载系统中可能是一个挑战。可解释性问题：机器学习模型，尤其是深度学习模型，往往是“黑箱”性质的，即其决策过程难以解释。这可能在安全关键的车载环境中引发信任问题，因为系统管理员可能难以理解和验证模型的判断。模型更新和维护：随着时间的推移，网络攻击手段不断演变，机器学习模型需要定期更新以保持其有效性。然而，频繁更新模型可能会影响系统的稳定性和一致性。51、3 AI 大模型在车端应用的演化趋势基于上文对 AI 大模型应用于车端的挑战分析，当前 AI 大模型上车主要面临算力、处理器性能、网络传输速率、数据存储等方面问题。针对这些问题，本文预判演化趋势如下：(1)模型压缩与优化随着模型压缩技术的发展，大型 AI 模型将能够在车端更小的硬件上运行，减少对存储和计算资源的需求。(2)实时性能优化通过算法优化和硬件加速，车端 AI 大模型将提供更快的响应速度和更高的处理效率。(3)边缘计算车端 AI 大模型将更多地依赖边缘计算，减少对云端的依赖，提高数据处理速度和实时性。(4)与移动通信技术的融合移动通信技术在通信速率、质量和数据量上直接影响了AI 大模型52、在车端的应用效果。AI 大模型将与移动通信技术进行深度融合，实现车辆与云端的高效通信和协同计算，为用户提供更加智能化的服务。(二)云端应用1 应用场景1.1 云端 VSOC如图 2.2-1汽车网络安全运营中心所示，云端 VSOC（VehicleSecurityOperationCenter，汽车安全运营中心，以下简称 VSOC）是一个专门负责监控、管理和保护车辆安全的综合性运营中心，它可以集中处理车辆安全事件、风险和威胁，并采取相应的响应和防御措施，以确保车辆和乘客的安全。VSOC 与AI 的结合能够极大提升汽车网络安全的检测、响应、分析和预防能力。通过智能化的威胁检测、自动化的中国汽车基础软53、件发展白皮书 5.0016事件响应、增强的数据分析和预测能力，AI 可以使 VSOC 系统更加高效和精确地应对现代汽车网络安全威胁。然而，在实际应用中，也需要解决数据隐私、模型维护、系统复杂性和资源消耗等挑战。图2.2-1 汽车网络安全运营中心结合车端深度学习小模型提供的事件数据和云端大数据及威胁情报资源作为安全运营训练数据跟 AI大模型的整合，可以显著提升汽车网络安全运营管理的效率。车端的小模型在车辆中实时运行，处理传感器数据、网络流量和系统日志，以快速检测异常活动和潜在威胁。这种模型具备低延迟、高效的实时检测能力，并且在计算资源有限的车载系统中表现优越。当车辆检测到异常时，车端会生成事件和54、告警，并将这些数据上传至云端。云端则利用强大的计算能力和丰富的威胁情报资源和专业的安全运营分析处置人员，对车端上传的事件和告警数据进行深入分析。云端的大数据平台结合大模型可以处理海量数据，结合全球范围的威胁情报，识别复杂的攻击模式和系统漏洞。通过这种方式，云端能够提供精准的威胁识别和深度分析，提高检测的准确性。事件处理过程分为自动化和半自动化两个阶段。云端系统可以根据分析结果自动化执行响应措施，如生成补丁、调整安全策略或触发警报。对于复杂的威胁，云端还可以提供决策支持和建议，供安全分析师进一步处理和决策。这种半自动化和全自动化的响应机制提升了事件处理的效率和有效性。此外，系统还包括一个反馈机制55、，云端将处理结果反馈给车端，以优化小模型的检测能力和响应策略。定期更新车端的小模型，结合最新的威胁情报和分析结果，不断提高其检测和处理能力。这种车云协同的安全架构具有实时与精准检测、高效资源利用、自动化与优化、全局视角、灵活性与适应性等显著优势。车端的小模型负责初步的异常检测，减少对云端计算资源的依赖；云端则处理复杂的分析任务，提供全球范围的安全态势感知和应对能力。通过结合车端和云端的优势，这一方案大大提升了汽车网络安全的防护能力，有效应对各种安全威胁，确保车辆的安全运行。1.2 性能预测与优化AI 大模型可以根据输入的汽车设计参数和性能目标，预测汽车的各项性能指标，通过对大量汽车工中国汽车基56、础软件发展白皮书 5.0017程数据的学习，大模型可以建立起汽车结构参数与性能指标之间的复杂关系模型，充分利用云端的强大算力和大数据能力，从而实现更高效、更智能的预测与优化。如图 2.2-2 所示，云端能量管理算法搭建了端到端的算法模型，首先将最影响能耗和续驶里程的驾驶员行为和行驶工况识别出来，通过构建驾驶员风格库与行驶工况库对不同的驾驶行为和行驶工况进行区分，获得其对能耗和续驶里程的影响的因子，再根据车辆的其他特征预测长驾驶周期的能耗和续驶里程。通过分析能耗和续驶里程，推荐相应驾驶模式并对加速踏板与制动能量回收强度实时更新，续驶里程不足时会进行相应的充电时间规划和节能路线导航。图2.2-2 57、性能预测与优化1.3 故障诊断与预测如图 2.2-3 故障检测与预测所示，利用先进的数据处理技术和 AI 大模型，实现对车辆健康状况的实时监控和预测性故障诊断。该系统通过实车采集的数据，结合云端的强大计算能力，对车辆的关键部件进行深入分析，从而提前发现潜在的故障和性能退化问题。及时发现潜在的故障隐患，并给出具体的故障诊断结果和维修建议。此外，大模型还可以通过对历史故障数据的学习，预测未来可能出现的故障，提前采取预防措施，降低汽车的故障率和维修成本。这不仅提高了汽车的可靠性，也减少了因故障导致的工程开发时间和成本浪费。图2.2-3 故障检测与预测中国汽车基础软件发展白皮书 5.00181.4 虚58、拟测试与验证传统的物理测试需要耗费大量的时间和成本。而 AI 大模型可以通过虚拟测试技术，对汽车的各项性能进行快速、准确的测试和验证。如图 2.2-4 虚拟测试与验证所示，通过 NVS 三维场景重建，AI 大模型可以快速更改测试条件，创建各种极端或特定测试场景，精确控制测试环境，如道路条件、天气状况等，以评估智能驾驶算法在不同环境下的安全性和有效性。图2.2-4 虚拟测试与验证这种模拟测试在汽车设计的早期阶段就识别出潜在的问题和性能瓶颈，显著缩短了工程开发周期，加快了新产品从概念到市场的转化速度，同时也提高了汽车软件的整体质量和性能。2 AI 大模型在云端应用的挑战AI 大模型在云端的应用面临59、着一系列挑战：(1)数据隐私与安全性智能网联的发展，让汽车的数据量激增，如何在云端安全地存储和处理这些数据成为一大挑战。数据隐私保护和网络安全是汽车制造商和供应商必须严格遵守的法规要求。(2)模型的可扩展性与维护云端 AI 大模型需要具备良好的可扩展性，以适应不断增长的数据和用户需求。同时，模型的持续维护和更新也是确保其长期有效性的关键。(3)实时性能要求云端 AI 大模型需要快速响应车辆的请求，以支持实时应用，如自动驾驶决策支持和远程监控。这要求云端具备高效的数据处理和分析能力。(4)跨平台兼容性汽车行业涉及多种硬件和软件平台，云端 AI 大模型需要在这些不同的平台之间实现兼容，以提供统一的60、服务和体验。3 AI 大模型在云端应用的演化趋势(1)边缘计算与云端协同中国汽车基础软件发展白皮书 5.0019随着边缘计算技术的发展，未来 AI 大模型将更多地在车辆端进行预处理，减少对云端的依赖，同时保持云端的强大分析和决策支持能力。(2)跨行业融合汽车行业将与其他行业如 IT、通信、能源等更紧密地融合，云端 AI 大模型将成为跨行业数据和应用集成的关键。(3)标准化与开源为了促进行业的健康发展，未来将有更多的 AI 大模型标准化工作和开源项目，以支持技术的共享和创新。中国汽车基础软件发展白皮书 5.0020三、开放式软件架构的中间件层纵观软件产业的发展历史，智能手机是一个极为成功的案例。61、作为软件规模最庞大的单一设备之一，智能手机具有独特特点：只有一个核心计算单元，传感器和执行器充分解耦和软件化。这种架构使得开发者在设计创新应用时无需深入了解底层操作，如访问摄像头或确保通信安全性和可靠性等问题，只需调用接口获取所需功能。这种体系和产业标准的支持，让应用开发者能专注于创新，各领域成熟组件能轻松协同运行，通过灵活编排和组合，创造出创新应用。在汽车产业方面，近十年来，各整车制造厂的电子电气架构逐渐演进至中央计算+区域控制的技术路线。因此，一个合理抽象整车基础硬件和系统、覆盖不同功能域的通信框架、为上层应用软件和生态提供更开放的开发平台中间件，已成为当前量产落地和持续创新的关键。（一）62、开放式软件架构的中间件以中央计算平台为硬件基础，多域融合的基础软件和应用中间件作为推动整车应用创新的软件底座，已经成为了行业的共识。在这样的技术路线上发展，产业要解决核心架构体系和框架问题，希望通过构建这样的体系和框架，让汽车软件的开发也可以像手机应用开发一样，为未来所有软件运行在同一颗芯片或计算平台上提供技术支撑并建立相应的软件架构、方法论以及工具链体系。如图 3.1-1ASF 中间件所示，ASF 中间件是在各个域控制器上都可以使用的、与业务无关的软件组件，是开发平台最基础、最核心的部分。ASF 中间件是面向下一代电子电气架构的开发平台，基于符合AUTOSAR 规范的标准基础软件，按照软件架63、构自下而上包含以下通用基础组件：标准中间件：面向 MCU 的标准基础软件和面向 SoC 的标准基础软件；车辆基础服务中间件：基于中国汽车基础软件生态委员会AUTOSEMO服务框架 ASF 技术规范开发；整车通信总线：解决整车通信总线问题，面向整车不同层级开发者视角；整车数据处理框架：统一的数据处理单元，作为管理域控平台的数据中心，用于解耦业务逻辑与数据处理；高效的开发框架和接口：将在本书第五章节作详细介绍。中国汽车基础软件发展白皮书 5.0021图3.1-1 ASF中间件1.面向 MCU 的标准基础软件1.1 面向 MCU 的标准基础软件介绍面向 MCU 的标准基础软件平台是一套专为 MCU 64、设计的嵌入式操作系统和开发环境，以 ClassicPlatformAUTOSAR 规范为代表，旨在为汽车电子控制单元提供高效、稳定、可靠的基础软件支持。该软件支持多任务调度、中断管理、通信协议、故障诊断等功能，能够满足不同车型和域控制器的开发需求。适用场景：l 适用于动力控制、底盘控制、车身控制等传统电子控制领域；l 支持多种 MCU 硬件平台，如 ARMCortex-M 系列、PowerPC 等；l 可与上层应用软件和操作系统无缝集成，提供完整的解决方案。面向 MCU 的标准基础软件起源于汽车电子控制领域对高效、可靠基础软件的需求。随着 AUTOSAR等国际标准的推出，面向 MCU 的标准基65、础软件逐渐走向标准化和模块化。目前，国内外多家厂商已推出基于 AUTOSAR 的 MCU 基础软件解决方案，并在汽车电子控制领域得到广泛应用。1.2 面向 MCU 的标准基础软件解读主要特点：l 标准化：遵循 ClassicPlatformAUTOSAR 等国际标准，提供统一的接口和服务；l 模块化：支持软件组件的模块化设计和复用，降低开发成本；l 高效性：采用实时操作系统和高效的任务调度机制，确保系统迅速响应；l 可靠性：内置故障诊断和自恢复机制，提高系统稳定性和安全性。重要特性：l 多任务调度：支持基于优先级的实时多任务调度；l 中断管理：提供灵活的中断配置和管理功能；l 通信协议：支持 66、CAN、LIN 等汽车电子通信协议；中国汽车基础软件发展白皮书 5.0022l 故障诊断：内置故障诊断和上报机制，便于故障排查和修复。关键技术：l 实时操作系统（RTOS）：提供高效的实时任务调度和同步机制；l 通信协议栈：支持多种汽车电子通信协议，确保数据交换的实时性和可靠性；l 故障诊断和上报：采用先进的故障诊断算法和上报机制，提高故障排查效率。1.3 面向 MCU 的标准基础软件发展趋势最新的 ClassicPlatformAUTOSAR 规范主要针对通信协议、接口标准化、内存操作、数据协议、质量属性、安全事件等方面进行强化和修改，主要集中在如下方面：新增 DDS 通信协议用于进行 DD67、S 服务化通信，新增 SENT（SingleEdgeNibbleTransmission，SENT）驱动用于标准化汽车传感器接口，新增车辆数据协议（VehicleDataProtocol，VDP）用于 ECU 之间的数据采集任务分发，修订 I2C 驱动规范，新增对内存标准函数库（MemoryStandardFunctionLibrary，MSFLibrary）的标准化。下面针对这些变化进行详细描述：a.DDS 通信协议：特性描述：针对 AUTOSAR 平台中服务实例的发现与广告场景，定义一套基于 DDS（DataDistri-butionService）的服务发现协议，包括服务实例的广告和服务68、实例的发现机制；定义服务的数据类型、QoS 策略、序列和语义，旨在支持 AUTOSAR 经典平台和自适应平台以及非 AUTOSAR 平台之间的 DDS互操作性。意义：通过标准化的服务发现协议，实现了 AUTOSAR 平台内及跨平台的服务互操作性，简化了服务实例的动态发现和绑定过程，提高了系统的灵活性和可扩展性；为 AUTOSAR 平台提供了一种高效、可靠的数据分发机制，支持复杂的实时通信需求，提高了系统的通信效率和可靠性。b.SENT 驱动：特性描述：针对汽车传感器接口标准化需求，提出了 SENT（SingleEdgeNibbleTransmission）协议的 API 标准化方案，定义 SE69、NT 驱动在 AUTOSAR 微控制器抽象层（MCAL）中的实现方式和接口规范。意义：通过 SENT 驱动的标准化，实现传感器应用程序与基础软件层的独立开发，提高软件的可重用性和兼容性，降低软件开发成本。c.车辆数据协议 VDP：特性描述：定义了一种用于在 ECU 之间分发数据采集任务的协议，支持动态配置数据采集点、异步错误报告等功能，旨在提高数据采集的灵活性和效率。意义：VDP 协议为车辆数据的高效采集和处理提供了一种标准化的解决方案，支持按需和循环采样模式，提高了数据采集的实时性和准确性。d.I2C 驱动：特性描述：对 I2C 驱动的规范进行修订，包括功能要求、API 接口和配置参数的标准70、化，新增对不同数据传输模式和错误处理机制的支持。意义：使得 I2C 驱动更加符合 AUTOSAR 标准的要求，提高驱动的稳定性，同时也增强驱动的可配置性和灵活性。e.内存标准函数库：特性描述：增加了对内存标准函数库的标准化要求，提供一套优化的内存操作函数，包括内存拷贝、内存移动、内存填充等功能。中国汽车基础软件发展白皮书 5.0023意义：简化内存操作的复杂性，提高代码的可移植性和可维护性。同时，通过提供优化的内存操作函数，提高程序的运行效率。2.面向 SoC 的标准基础软件2.1 面向 SoC 的标准基础软件介绍面向 SoC 的标准基础软件是一套专为高性能 SoC 设计的嵌入式操作系统和开发71、环境，旨在为智能网联汽车提供高效、安全、可扩展的基础软件支持。该软件遵循 AUTOSARAdaptivePlatform 等国际标准，支持多任务调度、实时通信、故障诊断、安全保护等功能，能够满足不同车型和域控制器的开发需求。适用场景：l 适用于自动驾驶、智能座舱、车载娱乐等高性能计算和高带宽需求场景；l 支持多种 SoC 硬件平台，如 ARMCortex-A 系列、NVIDIAXavier 等；l 可与上层应用软件和操作系统无缝集成，提供完整的解决方案。面向 SoC 的标准基础软件随着智能网联汽车的发展而兴起。随着 AUTOSARAdaptive 等国际标准的推出，面向 SoC 的标准基础软件72、逐渐走向标准化和模块化。目前，国内外多家厂商已推出基于 AdaptivePlatformAUTOSAR规范的SoC基础软件产品和解决方案，并在自动驾驶、智能座舱等领域得到广泛应用。2.2 面向 SoC 的标准基础软件解读主要特点：l 高性能：支持多任务并发处理和高速数据处理，适用于实时应用场景，如自动驾驶和车载信息娱乐系统；l 高带宽：提供支持高带宽需求的通信协议栈和基础服务，确保流媒体和大数据传输的流畅性；l 安全性：内置安全保护机制，防止恶意攻击和数据泄露，保障用户隐私和系统稳定性；l 可扩展性：支持软件组件的模块化设计和动态加载，便于功能扩展和升级。重要特性：l 多任务调度：支持基于优先73、级的实时多任务调度，确保任务按时执行；l 高带宽通信：提供高效的通信协议栈，支持大量数据传输和快速同步；l 故障诊断：内置故障诊断和上报机制，便于故障排查和修复；l 安全保护：支持加密、认证、防火墙等安全保护机制，确保系统安全。关键技术：l 安全可靠的操作系统：提供高效的任务调度机制和可靠的资源管理机制。l 高性能通信协议栈：支持 SOME/IP、DDS、TSN 等高性能通信协议。l 安全保护技术：采用加密、认证、防火墙等安全保护技术，确保系统安全。2.3 面向 SoC 的标准基础软件发展趋势新的 AUTOSARAP 规范主要针对汽车应用程序接口网关、自适应虚拟化等方面进行强化和修改，主要集中74、在如下方面：新增汽车 API 用于增强系统连接、数据交互能力，强化自适应平台的虚拟化特征用于虚拟化验证等场景。a)汽车 API：汽车 API 可以用于连接非AUTOSAR系统，使非AUTOSAR系统能够与车辆进行高效且安全的数据交换，适用标准化汽车 API 网关连接非AUTOSAR系统，可提高不同车辆和系统之间的兼容性和互操作性。其意义在于适应现代车辆中可能存在的多种不同类型系统的环境，促进汽车与其他领域技术的融合，中国汽车基础软件发展白皮书 5.0024为车辆提供更多的功能扩展和创新可能性。汽车 API 可以用于处理不同类型的数据，使用 ARXML（遵守 AUTOSAR 标准的通用的配置/数75、据库描述文件）描述 VSS 衍生服务接口，基于 VSS 目录定义服务接口，可以实现车辆数据在 AUTOSAR 环境中的访问和展示，并支持不同格式数据的映射和连接。其好处是确保车辆数据得到合理处理和利用，发挥数据价值，为不同应用场景提供准确数据支持。汽车 API 可以提供灵活的数据交互方式，汽车 API 网关可以提供基本的VISS操作（读、写、订阅数据），可以支持多种过滤器，用户可通过VISS协议访问车辆，网关负责实现VISS服务器功能并满足访问控制和传输协议要求。其意义在于满足不同用户和应用对车辆数据的访问需求，提高车辆数据服务质量和效率，为适应未来新传输协议和技术发展奠定基础。汽车 API 76、可以配置和管理网关功能，可以为网关提供ARXML，将 VSS 派生服务接口作为 RPort 进行描述，为开发人员提供更清晰的接口定义和配置信息。同时，能够确定网关配置方式，明确错误处理机制。其意义在于优化网关功能性能，满足不同场景需求，提升车辆系统质量和用户体验，为系统开发、维护和升级提供有力支持。b)自适应平台的虚拟化特征增强：评估虚拟化对 AUTOSARAP 的影响，包括虚拟化对处理器技术发展的益处和全面评估，包括对 AP架构、元模型、安全、功能集群等方面的影响，制定评估虚拟化影响的指南和方法。其意义在于全面了解虚拟化对 AUTOSARAP 各方面的影响，为后续的改进和优化提供依据。定义支77、持的虚拟系统配置和相关用例，包括两种系统配置：一是单机无虚拟化的配置，用于讨论和比较；二是虚拟系统配置，包括Type1Hypervisor下的非 APGuests（安全 Guest 和非安全 Guest）、混合临界性 APGuests（安全Guest 和 QMGuest）以及使用 OSHypervisor 的配置。其意义在于明确不同虚拟系统配置和用例的可实施情况，为虚拟化的实现和应用提供具体的场景和需求。制定虚拟化影响评估的方法和步骤，以“虚拟化将影响自适应平台”为前提，制定评估准则，包括功能集群影响评估（涵盖操作系统接口、执行管理、状态管理等多个元素）和安全影响评估。其意义在于提供一种系统化78、的评估方法，确保虚拟化的影响能够得到全面、准确的评估。考虑虚拟化相关的约束和假设，包括针对单机上的虚拟化和非虚拟化 AP，需要提供一致的平台视图；虚拟化系统中虽然可以存在多个 Machine，但只有一个AP实例运行在给定 Machine 中。其意义在于明确虚拟化的基本约束和假设，为虚拟化的实施提供基础和前提。确定与虚拟化相关的功能元素和架构组件，功能元素部分用于评估虚拟化对功能集群、清单、安全等的影响，架构组件部分包括在AUTOSAR分层软件架构中的集成、接口以及使用方法的定义，这些部分将在后续更新和完善。其意义在于明确功能元素和架构组件在虚拟化中的作用和影响，为虚拟化的设计和实现提供指导。379、.车辆基础服务车辆基础服务软件层是为多域融合而设计，针对分布式异构芯片环境，提供了一整套跨核、跨域协同的基础功能与服务。通过标准化的接口和协议，实现了各域控制器之间的无缝连接和数据交换，为上层应用软件提供了稳定、高效、灵活的开发环境；同时，车辆基础服务软件层还具备高度的可扩展性和灵活性，能够适应未来汽车电子电气架构的不断演进和升级。车辆基础服务软件层主要包含以下功能：l 跨核协同服务：针对异构多核处理器环境，提供高效的核间通信和任务调度机制，确保实时性中国汽车基础软件发展白皮书 5.0025和可靠性；l 电源管理服务：根据整车工作条件调整电源模式，以管控电源效率，合理降低功耗；l 日志管理服务80、：提供面向域控平台的整车日志统一管理机制，通过统一的工具进行日志收集和管理；l 信息安全服务：为整车提供系统级的信息安全策略，构建信息安全机制；l 健康管理服务：监控各域控制器的运行状态，及时发现并处理故障，保障整车系统的稳定性和安全性；l 时钟管理服务：实现整车时钟同步，确保各域控制器时间基准的一致性；l 存储管理服务：提供跨域、跨核的共享存储解决方案，支持数据的高效访问和备份；l 诊断管理服务：支持远程和本地诊断，提高故障诊断和修复的效率和准确性；l OTA 升级服务：实现整车级和域控制器的远程软件升级，提高软件的迭代速度和用户体验。目前AUTOSAR规范主要针对单 Machine 的场景81、进行了详细定义，但面向智能汽车的 SOA 架构和多域融合的应用开发，AUTOSAR未提供全面的支撑，应用开发者往往需要分别在 CP 和 AP 不同的体系平台上进行开发，再进行交互设计和集成。在这样的开发过程下，往往需要系统和软件的重新设计，以及工程过程重新适配和集成，这也是很多车型项目在量产开发过程后期遇到的工程成本问题。车辆基础服务中间件可以有效解决上述问题。车辆基础服务中间件在多域融合的架构下，可以将不同芯片、不同 ECU 甚至不同功能的资源进行协同处理和调用，并打通不同基础系统间的通信。车辆基础服务中间件在 AUTOSAR 基础软件规范的基础上进行接口封装、特性增强和场景扩展，解决快速创82、新的问题。3.1 车辆基础服务的适用场景面向分布式异构芯片的架构，“跨域协同”成为汽车软件功能的硬性需求，作为跨域协同服务的基础底座，其主要满足以下场景：1.满足异构芯片与异构核的场景：在新的电子电气架构下，域控制器成为了最核心的硬件，域控制器中包含多个异构的处理核心（SoC、MCU及各类专用芯片），为了达成实时性、安全性、高算力、高带宽等系统需求，往往需要多个异构核进行调度、通信、资源管理更多方面的协同合作，因此跨域协同（包括域控制内异构核之间协同，以及多个域控制器芯片之间协同）的需求越来越多，成为了支撑创新的主要动力和重要基础。车辆基础服务中间件可以提供跨域协同需要的基础能力，例如整车 O83、TA、整车级健康管理、域控级的诊断协同等。2.整车级 SOA 场景：车辆基础服务中间件提供整车层面上覆盖所有控制器的统一 SOA 框架。针对多域融合的场景，打通域间资源协调、管理域间通信、对应用开发提供完整 ECU 级别乃至整车级别开发视角的软件组件层平台；借此实现中间层软硬解耦，应用层软软解耦，将整车功能原子化后抽象成可调用的 SOA服务，并制定清晰标准的交互接口，为多车型适配提供一致的开发界面，为汽车应用生态提供统一的开放底座。3.工具链融合场景：由于历史发展的原因，AUTOSARClassic/Adaptive规范针对 MCU 与 SoC 的开发方法学方面有一定程度的割裂，当前的工具链实84、践也往往是各自开发。而在域控制器架构下，很多功能需要 MCU 与 SoC 进行协同，这就要使用两套工具链分别开发，导致开发难度增加，后续的调试效率也受到很大影响。车辆基础服务中间件工具链可以为用户提供统一的开发视图，它集成了跨域服务开发所需的各组件，提供整车跨域跨核应用层所需要的基础服务，例如健康管理中间件、诊断管理中间件、中国汽车基础软件发展白皮书 5.0026存储管理中间件、核间通信中间件、日志管理中间件、OTA 中间件等模块的配置与代码生成。3.2 车辆基础服务的定义如图 3.1-2 车辆基础服务中间件所示，车辆基础服务中间件是基于 AUTOSAR基础软件之上的开发组件，实现基于 AUT85、OSAR 规范的扩充和增强，同时支持跨核跨域协同的系统级基础功能，支持健康管理、整车日志、整车时钟、远程诊断、OTA 等更加丰富的整车级基础服务，对用户提供统一的开发视图，解决现有AUTOSAR 标准基础软件平台在使用门槛高、新应用功能场景定义不足，以及针对大算力多核异构平台的跨域应用局限性等问题。针对创新车载应用和新一代电子电气架构，车辆基础服务中间件将为汽车应用开发者提供面向整车的通信、诊断、存储、升级、监控、时钟等基础服务框架和接口，加速汽车应用开发的迭代速度。图3.1-2 车辆基础服务中间件3.3 车辆基础服务的功能车辆基础服务中间件主要包括如下功能：1）核间通信（Inter-Core86、Comm），在多核异构域控系统中，MCU 依然承担大量的实时数据的逻辑处理工作，为了减轻 MCU 的负载，需要打通 MCU 与 SoC之间的数据通道，实现 MCU 与 SoC 之间的数据协同。与此同时，还应该提供MCU信号与 SOA 服务之间的转换功能，以及在以太网上进行服务发布的能力，才能解决信号与服务的跨核双向快速转化的问题。因此，本模块的核心特性应该包括：（1）核间通信协议：面向服务的通信协议，提供 Method 以及 Event 语义；为 MCU 和 SoC 之间提供跨核通信方式，为 SoC 内部不同进程提供进程间的通信方式；（2）信号转服务通信：提供 MCU 功能在 SoC 进行服务87、化的能力：l SoC 服务直接映射为 MCURTE 接口或 CAN 信号，SoC 侧应用操作 SOA 服务对 RTE 接口或CAN 信号进行设定，MCU 侧借助 SWC 使用 RTE 接口即可完成对 SoC 服务的操作。这样可以对 MCU 上已有的基于 CAN 信号和 RTE 开发的 SWC 直接接入 SOA 架构，实现零成本迁移和资产复用；l 提供完备的 SOAEvent、Method、Getter、Setter、Notifier 语义，覆盖全面的使用场景；中国汽车基础软件发展白皮书 5.0027l 提供可视化工具支持 SOA 服务设计，全自动生成 AUTOSARARXML 与 SOA 代码88、，支持低成本、快速的、多样化的服务设计与应用或 SWC 的开发迭代。2）存储管理（StorageManagement），存储中间件为域控应用提供了一套统一的存储器访问代理和接口封装，使应用开发者能够对应用数据的存储进行系统层面的统一设计和配置，而无需深入了解底层 AP 和 CP 的接口细节，配合内部的存储管理策略，可以实现数据和文件的跨核访问和共享策略管理，具体功能包括：（1）跨核存储：实现跨核共享存储，提供 MCU 跨核读写 SOC 数据的服务；（2）存储策略：支持立即存储、周期存储、下电存储等策略；（3）多进程访问：通过本地网络通信实现 SOC 内多个进程之间共享键值存储；（4）AUTOS89、AR 扩展：封装 AUTOSARAdaptive的 PER 模块文件读写、键值读写功能接口，新增应用所在目录下文件、键值库的权限控制，并支持设置文件、键值库存储策略；（5）压缩解压：支持应用目录下的文件和目录压缩，支持将应用目录下的压缩文件解压到应用目录下的子目录；（6）查询应用存储容量：为应用提供查询本应用的最大存储容量、已使用容量、剩余容量；（7）查询存储分区容量：支持查询磁盘分区容量，具体包括查询容量时的时间、分区名称、分区总容量、分区已使用容量、分区剩余可用容量、分区已使用容量百分比、分区挂载路径。3）健康管理（HealthManagement），目前 AUTOSARAdaptiveP90、latform 的健康管理仅定义了针对自适应平台应用的健康监控机制，缺乏面向域控场景的系统健康管理定义；健康管理中间件基于 AU-TOSAR 进行了特性增强和扩展，为域控应用提供跨核、跨域的健康和信息收集，以及对操作系统的健康状态监控，具体功能包括：（1）域内健康报告：报告域内各个 MCU/SOC 的健康状态（主要是故障信息），健康报告内容包括资源故障、应用故障、Nor-Flash 故障、硬件故障、功能逻辑故障、健康指数、故障上报时的车况信息等；（2）POSIXOS 健康检测：报告域内各个 MCU/SoC 的实时数据（主要是资源使用情况），实时数据内容包括 EMMC 空间、CPU 使用率、内存91、占用情况、句柄占用情况、进程信息等，以及心跳监测 MCU/SoC 是否在线。4）时钟管理（ClockManagement），AUTOSARTS 模块只定义了 gPTP 等协议栈及其配置的功能；但在域控平台的使用场景下，需要对车辆的多个时钟源进行选择，并对整车各 ECU 的时钟进行同步。时钟管理中间件提供多时钟源管理、跨 ECU 时间同步等功能，保证整车时钟的一致性，具体功能包括：（1）RTC时钟源管理：获取当前RTC时间，或在有更高优先级时钟源信号时向RTC写入当前时间信息；（2）NTP 时钟管理：通过 NTP 协议从 NTP 服务器上获取当前时间；（3）GPS 时钟管理：获取 GPS 模块提92、供的时间信息；（4）时钟源管理策略：用户可以设置各时钟源的优先级，自动根据运行时各时钟源的可用状态选择时钟源作为整车时钟的基准时间；（5）跨核时钟同步：基于时钟管理策略配置确定特定时钟源的时钟，并通过 gPTP 协议向其他 ECU发布，保证整车时钟的一致性。5）电源管理（PowerManagement），ECU 需要根据整车的工作条件调整自身的电源模式，以满足车辆各 ECU 对电源功耗的需求和控制策略，具体功能包括：（1）电源管理：负责管理域控制器的电源状态；由运行在 MCU 中的电源管理主控程序，管理其他中国汽车基础软件发展白皮书 5.0028Partition 中运行电源管理的 Slave93、 程序；电源管理主控程序负责维护域控制器整体电源状态，执行上下电流程；Slave 程序负责同步电源状态到各个 Partition，并执行主控程序的电源命令；（2）电源模式迁移：支持电源模式在 Gateway（启动前过度）、Run（正常工作）、Standby（低功耗待机）、Reset（复位）之间进行状态迁移。6）日志管理（LogManagement），AUTOSARCP 和 AP 标准仅定义了面向单个 Machine 的日志管理机制，但域控制器通常包含多个 MCU/SoC，因此不得不针对每一个 MCU/SOC 进行独立的日志管理部署；日志中间件对 AUTOSAR 规范进行特性扩展和接口封装，提供94、了面向域控平台跨芯片乃至跨整车 ECU 的日志统一管理策略，域控应用开发者可通过统一的工具进行日志管理，具体功能包括：（1）日志收集：支持跨核、跨域收集，支持以太网、CAN 总线日志收集，支持内核、网卡、CoreDump 等日志收集，支持日志存储路径、空间统一规划管理；（2）日志控制：支持云端和诊断仪控制整车日志，以及日志等级过滤的开关控制；（3）日志导出：支持日志上传云端、车机以及线上浏览。7）诊断管理（DiagnosticManagement），AUTOSAR 规范定义了 DCM 和 DEM，来支持单 Ma-chine 场景下的诊断服务，而面向域控架构的场景下，需要满足更多更复杂的诊断场景95、，如远程诊断、跨核诊断等；诊断管理中间件在 AUTOSARCP 和 AP 的基础上，需要构建面向跨域的诊断管理和通信机制，具体功能包括：（1）远程诊断：包括远程或诊断仪 ODX/OTX 脚本下载、解析、车云交互，以及诊断报告的生成、存储和上传；（2）安全认证：支持诊断仪与诊断管理中间件的双向认证功能；（3）诊断仲裁：支持多诊断仪并发诊断时的仲裁功能；（4）诊断路由：外部设备发送到诊断管理中间件的诊断请求，根据诊断路由表分发到相应的器件中，由器件中部署的 DM 模块处理诊断请求，处理结果通过诊断管理中间件反馈给外部设备。8）OTA（Over-the-Air），构建面向整车的新型系统级 OTA 方96、案，包括软件包下载、刷写报文路由转发、刷写代理、版本号管理及软件包验签、软件包分发等，同时支持 FOTA、SOTA 刷写，需要能够识别多种异常情况，并支持在线识别及处理等，具体功能包括：（1）车云车机交互：l 支持车辆注册、更新车辆配置、升级检查；l 支持制车车辆包制作、传输；l 支持升级模式设置（立即升级、预约升级、夜间自动升级）；（2）OTA 升级策略：l 支持各域控制器的升级；l 支持符合 ETH、CAN、LIN 规范的 ECU 的升级；（3）OTA 升级激活配置：l 支持注册激活 OTA 功能；l 支持升级软件的检查更新；（4）OTA 升级任务管理：l 支持 OTA 升级包下载管理；l97、 支持 OTA 升级模式管理（主动升级、静默升级）；中国汽车基础软件发展白皮书 5.0029l 支持分组升级管理，同组 ECU 同升同降；l 支持升级版本管理；（5）OTA 升级阶段管理：l 支持升级包同步、回滚、删除；l 支持升级阶段状态管理，包括软件包升级环境准备、环境检查、环境恢复；l 支持 ECU 配电管理；（6）信息安全：l 支持下载软件包时的安全通信和软件包的解密/验签；l 支持以太网诊断仪刷写 ECU 时的安全认证。9）信息安全中间件（Cyberseurity），AUTOSARAP 可提供加密计算、密钥存储及证书存储相关接口，但存在接口调用过程繁琐、场景支持不足等问题；通过构建域98、控级信息安全中间件，对 APCrypto 接口进行封装及特性扩展，为域控应用在通信、诊断和升级等方面提供系统级的信息安全策略，具体功能包括随机数生成、散列计算、对称加解密、签名验签、证书验证、证书链验证、导入导出密钥、导入导出证书、Base64 编解码等功能。3.4 车辆基础服务的关键技术与实施挑战车辆基础服务中间件作为面向 SOA 架构的域控级乃至整车级的基础服务平台，是通过服务定义来体现对标准基础软件和操作系统的扩展和封装能力的，因此服务的定义/设计需要遵循一定的规范性要求，才能真正提高软件架构的鲁棒性、软件的稳定性和系统的整体性能。服务设计作为一个关键技术，其基本要求如下：a.服务具有独99、立性：即服务设计应与硬件配置和实现无关，与上层功能服务层和下层硬件驱动层解耦，完全独立；b.服务具有原子性：即设计的服务不可再拆分，作为服务的最小单位和执行实体，为上层功能提供最基础的执行或采集等功能；c.SOA 增强服务具有通用性：在 AUTOSARCP/AP 的基础之上，为应用提供领域级的通用基础能力，如数据存储、服务信号转换、服务调试等诸如此类的通用性功能；d.整车级系统服务具有全局性：即该类服务的设计更多关注是整车层面对整车内所有系统能力进行协同和管控，该层服务是对系统基础服务在整车层面的抽象和封装，即通过该层服务可以配置和控制系统基础服务，如整车健康管理服务、整车网络管理服务、整车时100、钟服务、整车电源管理服务等。车辆基础服务中间件的实施面临多个挑战，这些挑战主要源于不同系统、平台之间的技术差异、安全要求以及数据交互的复杂性。主要体现为以下几点：a.技术架构与兼容性挑战：不同域控制器和系统可能采用不同的技术架构，导致中间件在集成时需要考虑多种技术的兼容性；中间件需要支持多种接口标准并进行相应的转换和适配。b.性能与效率挑战：跨域通信涉及网络延迟、带宽限制等问题，中间件需要优化数据传输策略以提高传输效率；同时，中间件需要处理来自不同系统的并发请求并快速响应，这对中间件的并发处理能力和扩展性提出了高要求。c.安全与可靠性挑战：中国汽车基础软件发展白皮书 5.0030中间件需要确保101、数据传输过程中的安全性和隐私保护，防止数据泄露和非法访问；中间件需要具备高度的可靠性和稳定性，以确保整车系统的正常运行和故障排查。d.部署与维护挑战：跨域中间件的部署可能涉及多个系统、平台的集成和配置，部署过程复杂且容易出错；维护和升级也是一大挑战，需要开发团队具备专业的技能和经验以确保中间件的稳定运行和持续优化。e.法规与合规性挑战：随着数据保护法规的日益严格，中间件需要确保数据传输和处理过程符合相关法规要求；这要求各开发团队密切关注法规动态并及时调整中间件的设计和实现以满足合规性要求。3.5 车辆基础服务 API如图 3.1-3 车辆基础服务 API 所示，车辆基础服务中间件通过封装下层的102、基础软件和操作系统，对上层提供基础的跨域协同服务组件和功能接口，为上层平台和应用提供了更多面向服务开发所需要的服务和接口，接口概览图如下：图3.1-3 车辆基础服务API 车辆基础服务中间件为上层应用提供的接口以及对下层组件的接口依赖参考表 3.1-1车辆基础服务API。表3.1-1 车辆基础服务API组件SOC 应用层接口MCU 应用接口对 AP 接口依赖对 CP 接口依赖核间通信向应用提供方法（Method）和事件（Event）的服务发布和订阅接口作为客户端，为 MCU 侧应用提供 SOC 侧发送的事 件（Event）数 据，并处理方法（Method）调用；作为服务端，向 SOC 侧请求方103、法（Method）服务。依赖 LT、PHM 和EM 模 块 所 提 供的接口无中国汽车基础软件发展白皮书 5.0031组件SOC 应用层接口MCU 应用接口对 AP 接口依赖对 CP 接口依赖存储管理文件读写功能接口;键值读写功能接口;设置与查询应用存储容量功能接口;压缩解压功能接口;查询存储分区容量接口;核内共享 KV 存储功能接口;MCU 与 SOC 跨核共享存储服务接口MCU 本地回读与存储服务接口依赖 PER、LT、PHM 和 EM 模块所提供的接口；依 赖 NvM模块。健康管理PHM、系统健康监控、存储管理等组件向本组件（健康管理组件）发送故障信息接口；PHM 向本组件（健康管理组件104、）周期发送核间心跳接口。PHM 向本组件（健康管理组件）发送硬重置（HardRe-set）请求接口;PHM，系统健康监控向本组件（健康管理组件）发送实时信息接口监视结果发送接口依赖 PER、LT、PHM 和 EM 模块所提供的接口依赖网络连接接口；依赖数据获取 与 发 送接口。时钟管理获取 NTP 状态接口;获取时区状态接口获取绝对时间、相对时间接口；时间转换接口；设置、获取、查找、删除绝对时间、相对时间预约唤醒接口；查询预约的绝对时间、相对时间闹钟接口;共享电源状态接口。依赖 LT 和 TS 模块所提供的接口依赖获取、设 置 时 间接口；依赖获取时间 基 状 态接口;依 赖 StbM模块。电105、源管理无重启 Partition、整板接口；快速下电接口；Partition 下电；获取 Partition 状态接口；状态变化通知接口。延时关机接口。依赖 LT 和 SM 模块所提供的接口无中国汽车基础软件发展白皮书 5.0032组件SOC 应用层接口MCU 应用接口对 AP 接口依赖对 CP 接口依赖日志管理基本类型的打印输出接口;日志打印等级管理接口打印目标控制接口。依赖 LT 模块；依 赖 DLT和 STBM模块所提供的接口。诊断管理安全认证接口;0 x10/0 x11/0 x14/0 x-19/0 x22/0 x27/0 x28/0 x-29/0 x2E/0 x31/0 x34/0 106、x-35/0 x36/0 x37/0 x38/0 x-3e/0 x85 服务接口;功能寻址接口;初始化函数和周期函数;ETH 数据收发接口;CAN 数据收发接口。依赖 LT、PHM 和EM 模 块 所 提 供的接口依赖ETHTP、CANTP 和DCM 模块接口。OTA软件包下载阶段管理接口，包括下载、查询、断点续传、完整性检查等;软件包处理阶段接口，包括处理、防降级、同组升级等;软件包安装阶段接口，包括升级环境检查与恢复、升级超时、升级重试、升级控制等接口;升级阶段状态管理接口，包括升级状态、进度上报，升级结果查询等接口;版本管理接口，包括版本巡检、依赖性检查等接口；升级包处理接口，包括升级包107、同步、回滚、删除等接口;配电管理接口，包括 ECU 智能配电，蓄电池补电等操作;车云车机交互接口，包括车辆注册、升级检查、车辆包传输、升级触发等接口。升级条件校验;请求下载、传输接口;升级包同步、回滚、删除等接口;A-B 分区同步接口;网络通信接口。依 赖 CM、DM、LT和 EM 模块所提供的接口无4.整车通信总线在软件的发展史上，对于分布式系统，为了实现软件复用，开发平台需要提供一套针对异构节点的统一接口抽象与方法论支撑的通信框架，以实现应用可以一致性的开发和动态部署；从而让软件解耦更充分，达成最大限度的软件资产复用。中国汽车基础软件发展白皮书 5.0033传统的电子电气架构下，汽车软件（108、除了座舱域）是个典型的分布式同构系统，以 MCU 上的软件开发为主，为了实现针对应用的复用与动态部署，AUTOSARClassic 标准提供了 VFB（VirtualFunctionBus）的概念，基于 VFB 开发的应用，可以在不同的控制器上进行复用与迁移。如今的新电子电气架构下，域控制器的出现，改变了汽车软件的底层形态，从分布式同构系统变成了分布式异构系统。虽然“集中式”趋势越来越明显，但从整车上看，未来很长一段时间内，汽车内仍然会有多个控制器，仍然依赖异构处理器来承载软件功能，包括 MCU、SOC、GPU、NPU 等各种架构的处理器；同时用于车内/车外通信的物理总线也越来越多，网络拓扑越109、来越复杂，通信协议体量越来越大。因此，AUTOSAR 试图建立统一的通信框架，使用了基于 SOA 的通信方式，但这部分主要以规范POSIX 系统上的以太网为主；同时为了支持与 MCU 之间基于信号的通信方式，提出了 S2S（SignaltoService），但使用限制较多，使用方法复杂。与此同时，由于各行业的开发者进入汽车软件领域，其背景和开发习惯各有不同，对于 AUTOSAR 的极其严谨的、静态配置为主的、欠缺灵活性的开发方法学难以适应。因此目前汽车软件领域急需一种可以满足灵活部署、动态适应、快速调试、高效协同的开发体系，同时还必须满足清晰的边界定义和严格的过程要求，因此目前主流的自动驾驶开110、发者倾向于使用比较灵活的 Topic 类的接口，但是又存在可靠性问题亟待解决。基于以上行业变革带来的影响下，目前通信框架（例如 SOME/IP、ROS、DDS 等）都难以满足行业发展趋势的要求，亟需一种新的整车通信总线。4.1 整车通信总线的适用场景整车通信总线作为汽车内部信息交互的基础设施，其适用场景随着技术的发展而不断扩展，为智能汽车的多样化功能提供了坚实的通信基础，同时也为汽车产业的创新和发展开辟了新的道路。随着汽车向更高级别的智能化和自动化发展，整车通信总线的重要性将愈发凸显。车辆内外部需求不断增加，需要支持车辆与外部网络间以及内部不同的系统组件间的通信，故不能再局限于单一的通信技术和111、协议栈，而是需要融合多种通信技术，以适应不同的应用场景和需求。1.多域控制器之间的统一通信管理不同域控制器可能运行者不同的硬件平台和操作系统，且采用不同的通信协议。整车通信总线可以提供一个封装层软件，屏蔽上述差异，实现统一的通信语义。这不仅简化了系统集成，也大大提高了系统的可扩展性和维护性。2.复杂的域内通信需求在域内通信中，通常需要支持高效的、低延迟的通信协议，以确保系统的实时性和可靠性。例如，在一个车载娱乐系统中，不同的控制模块之间可能需要快速交换大量的多媒体数据。这种情况下，整车通信总线可以通过支持协议缓存（Protobuf）、快速二进制（FastBinary）等高效序列化协议，以及针对112、域内通信的优化通道管理，确保数据的快速传输和处理。3.不同开发体系和语言的集成随着新供应商和新技术加入汽车软件领域，汽车软件架构需要兼容适配不同的开发语言和技术框架。整车通信总线通过提供多语言编程接口和兼容的开发体系，确保不同团队开发的模块可以快速集成，这在跨平台、跨团队开发时尤为重要，特别是在需要集成第三方系统（如 ROS）时，整车通信总线可以提供必要的接口抽象能力，可以确保系统的互操作性。4.面向自动驾驶的高性能数据处理自动驾驶汽车需要处理大量传感器数据，并实时做出决策。这要求整车通信总线不仅能够高效地传中国汽车基础软件发展白皮书 5.0034输和处理数据，还需要提供支持数据埋点、QoS 113、策略等高级功能，以确保数据的可靠性和实时性。此外，自动驾驶系统中的多个传感器和控制器之间的数据同步和信息融合，也是整车通信总线的一个重要应用场景，通过缓存融合与同步功能，框架可以自动处理数据的收集与打包，并确保数据的一致性。5.车云之间的通信随着车联网技术的普及，车辆与云端之间的通信需求也在不断增加。整车通信总线通过支持多种网络协议（TCP、UDP、SOME/IP、DDS），可以确保车辆可以在不同的通信环境中与云端顺畅互联，并支持快速适配和迁移，这为远程诊断、OTA 升级和智能网联服务提供基础能力。4.2 整车通信总线的定义整车通信总线是为了简化复杂车载系统的设计和开发提出的一种面向服务架构(114、SOA)的中间件解决方案。它将业务逻辑实现与特定目标平台的通信层细节隔离开来，使用与编程语言无关的接口模型定义来生成完整的服务 API 和底层传输层和序列化层，支持跨域以及域内通信，为分布式异构网络实现高效、可靠、安全的通信。整车通信总线的核心能力在于为分布式异构系统，尤其是以域控制器为核心的整车网络提供一个抽象且统一的通信语义平台。该框架通过高度抽象的通信模型和协议转换机制，实现对整车级通信资源的有效管理和优化配置，可以满足车内/车外的高效稳定通信需求。如图 3.1-4 整车通信总线所示，整车通信总线抽象了各种软件应用程序和 ECU 之间的底层通信协议，这种抽象让开发人员摆脱项目环境特定的通115、信机制，并允许他们专注于业务代码的开发，而不受特定于操作系统或项目部署设置（网络拓扑、协议栈）的细节的影响。基于整车通信总线开发的应用程序需要在车辆内的不同平台之间移动时基本无需在接口进行任何更改，做到开发一次，部署到多个平台或者 ECU，这大大缩短了开发过程中的功能交付时间，缩短了整个产品的交付周期。具体而言，整车通信总线定义为一个多层次的通信中间件，它跨越了不同操作系统、物理总线、网络协议和开发语言的界限，为整车通信提供了一种标准化的交互接口。该框架不仅整合了车内复杂的通信需求，还通过抽象化的通信语义，使得上层应用开发能够忽略底层硬件和协议的差异，从而大大简化了开发流程，提高了系统的可维护116、性和可扩展性。在架构设计上，整车通信总线采用模块化设计思想，将通信服务划分为接口层、域内通信层、域间通信层等多个层次，每个层次针对特定的通信场景提供专业的解决方案。通过这种方式，整车通信总线不仅实现了对多样化通信场景的统一封装，还保证了不同场景下通信的高效性和可靠性。图3.1-4 整车通信总线 中国汽车基础软件发展白皮书 5.0035整车通信总线的主要特点如下：l 支持面向服务（SOA）的软件架构，可以支持跨域的服务调用。l 基于接口模型自动生成的 API 接口，并自动生成序列化和传输层，手动编码仅剩业务逻辑，显著减少工作量，并降低引入错误的风险。l 业务代码与平台的底层通信层细节分离，平台的117、任何更改都不会影响业务逻辑代码。l 使用与平台无关的接口定义语言来定义接口，应用程序需要在车辆内的不同平台之间移动时无需进行任何更改，可以做到开发一次，部署到多个平台或者 ECU。l 提供完善的通信机制和远程调用机制，无论服务或客户端应用程序在何处运行（本地或远程）以及使用何种通信机制，应用程序的实现始终相同。4.3 整车通信总线的功能为了促进整车系统中各组件之间的通信和协作，提高异构场景中整车通信的互操作性和可扩展性，就需要实现具有统一通信界面的整车通信总线。统一通信框架可提供整车标准化统一接口，简化整车系统中不同组件之间的通信过程，定义数据传输的规则、消息格式、通信协议和安全措施，用于管理118、不同子系统、组件和传感器之间的通信，可简化系统的复杂性，提升通信的效率和可靠性，提高系统的灵活性和可维护性，有助于实现车辆智能化、自动化和网络化。整车通信总线提供如下主要功能：1.跨系统和协议的一致性封装整车通信总线实现了对各类系统、物理总线、网络协议和开发语言的统一封装，提供了一致性的接口。无论是不同的操作系统、网络架构还是开发环境，都能够通过框架进行无缝集成和互操作，极大简化了跨平台开发的复杂性。2.多样化通信语义支持整车通信总线为应用层提供了丰富的通信语义支持，包括数据驱动的 Topic 模型和方法调用的Method 模型。这使得开发者能够以更灵活的方式进行应用开发，类似于 SOME/I119、P 和 DDS 等协议，满足不同应用场景下的通信需求。3.全场景通信支持整车通信总线适配多种通信场景，支持从 RTOS、POSIX、Android 等多种操作系统，并且兼容 CAN、LIN、以太网、PCIe、SPI 等多种物理通信总线。无论是车内外不同节点间的通信，还是域控制器内部的多处理器间通信，框架都能够提供稳定可靠的支持。4.高效核间通信在多核架构的车载系统中，整车通信总线确保了 MCU 与 SOC 之间的高性能数据交换能力，支持与AUTOSAR 开发体系的直接对接，优化了核间通信效率，确保了系统的整体性能和响应速度。5.灵活的序列化机制整车通信总线提供灵活的序列化支持，通过自动配置，优120、化数据传输的序列化方式，确保不同部署场景下的通信效率。应用层与底层序列化实现完全解耦，框架能够根据部署环境自动推导出最优的序列化策略，简化开发和维护。6.端到端 QoS 保障整车通信总线通过端到端的质量服务保障，支持多 Topic 数据的缓存融合与同步，确保数据在传输过程中的及时性和完整性。无论是实时性要求高的应用场景，还是对数据可靠性有严苛要求的场景，框架都需要提供强有力的支持。中国汽车基础软件发展白皮书 5.00367.域内消息与整车协议映射整车通信总线内置 CMBridge 功能，实现域内消息与整车 SOME/IP 协议的映射，确保不同域控制器之间的通信能力。这种映射机制为整车通信架构提121、供了强大的灵活性和扩展能力。8.动态任务编排与智能调度整车通信总线具备动态任务编排和智能调度能力，能够根据系统的运行状态和负载情况，灵活调整任务的执行顺序和优先级，从而提升系统的整体运行效率和资源利用率。9.数据监控与仿真能力整车通信总线支持全面的数据监控与仿真功能，为开发者提供了实时的数据流监控和仿真测试支持。这一能力有助于在系统开发和调试过程中发现隐藏问题，确保产品在集成前达到最佳状态。4.4 整车通信总线的关键技术与实施挑战整车通信总线的设计与实现需要在多个层面上进行创新与突破，从统一语义的接口设计到安全稳定的通信机制，每一个环节都涉及复杂的技术挑战。解决这些挑战不仅需要在技术上提供创新122、的解决方案，还需要在开发流程、工具链支持、生态系统建设等方面进行系统性的优化。未来的通信框架将决定整车电子电气架构的效率和可靠性，是推动智能化和自动化发展的核心基础。首先，随着汽车智能化、电动化、网联化的发展，传感器数量和数据量的增加对电子电气架构提出了更高的要求。传统的分布扁平式电子电气架构因缺乏主导分层融合的主节点，导致硬件资源浪费、线束布置复杂、基础软件难以标准化等问题。为了应对这些挑战，需要升级现有电子电气架构，通过硬件资源共享、软件标准化简化整车布置，实现轻量化和功能优化。其次，中央计算平台的引入为整车通信带来了新的技术挑战。高算力的异构芯片需要在不同芯片上进行整车功能部署和资源划分123、，这要求具备良好的系统、硬软件架构设计能力，以及持续集成与交付的软件开发体系。再次，开放式平台的构建也是整车通信总线的一个重要方面。它要求硬件系统具备灵活的可扩展性，并建立开放的软件生态，包括稳定的操作系统、底层驱动、虚拟化环境以及统一的中间件技术和服务接口。再次，在安全性方面，整车通信总线需要面对日益增长的网络安全威胁。随着汽车电子化程度的提高，车辆可能成为黑客攻击的目标。因此，需要采取有效的网络安全措施，如数据加密、身份验证和访问控制，以保护车辆通信不受未授权访问和攻击。此外，车联网通信的低时延和高可靠性要求也是整车通信总线需要解决的关键问题。例如，远程驾驶、自动泊车等场景要求端到端的时延124、达到毫秒级，甚至是微秒级，可靠性要求极高。这就需要 5G 车联网技术的支持，但 5G 技术在车联网领域的应用还面临诸多挑战，如与公众通信的区别、上下行时隙配比问题、频率资源分配等。最后，自动驾驶汽车的通信力和抗干扰能力也是整车通信总线需要重点关注的领域。自动驾驶汽车需要在动态多变的道路环境中进行感知和决策，这就需要强大的通信能力和抗干扰技术来保证车辆能够准确获取环境信息并做出正确的决策。基于以上论述，可以总结出如下几个要点的关键技术和实施挑战：1.统一语义的接口设计关键技术：l 分布式系统的集中式开发视图：在面对不同物理总线、网络协议和开发语言的分布式异构系统时，统一语义接口的设计是关键。需要125、提供一种能够在不同系统和平台之间保持一致性和兼容中国汽车基础软件发展白皮书 5.0037性的接口，确保开发人员能够以一种集中式的方式进行开发和部署。l 统一的服务接口语义：通过标准化的服务接口语义（例如，SOME/IP 和 DDS 协议的封装），开发者可以在分布式系统中实现组件的统一管理和部署。实施挑战：l 跨域协同的复杂性：由于不同域（如动力域、智驾域等）有不同的实时性和安全性要求，如何在不牺牲个性化需求的情况下实现统一的接口设计，是一个主要挑战。l 工具链兼容性与开发便捷性：现有的 AUTOSAR 工具链在便利性方面还有提升空间，特别是在面向服务的通信中，如何简化 IDL（arxml）生成126、与修改过程，降低开发难度，是重要的挑战。2.多层次的组件设计与服务化通信关键技术：l 面向服务的通信架构：通过采用 SOME/IP、DDS 等面向服务的通信协议，实现跨不同开发场景的灵活组件复用，同时确保系统的严谨性和可靠性。l 开源中间件的集成：例如，将 ROS2 等开源中间件整合进整车架构中，利用其成熟的生态系统加速算法和应用的开发，同时提供更加轻量化的接口修改方式。实施挑战：l 开源框架的量产适应性：ROS2 等开源框架虽然具备强大的生态，但其庞大的代码量和开源性质可能在量产阶段带来风险。如何保证这些开源组件在汽车应用中的安全性和稳定性，并确保其与传统 AUTOSAR 体系的兼容，是关键127、问题。l 异构系统的统一部署：如何在 MCU、SOC 和 Android 系统上实现统一的通信框架，并保证各平台之间的协同工作，是需要解决的难题。3.生态系统的友好性与分布式开发支持关键技术：l 分布式协同开发：为了支持多方异地、分时开发，需要通信框架能够灵活适应不同开发周期和组织的需求，确保各模块在开发过程中的接口稳定性和兼容性。l 模块化集成与扩展性：随着架构层次的细化，需要具备强大的模块集成能力，将不同开发周期和要求的模块快速集成到现有系统中。实施挑战：l 接口稳定性与版本管理：在多方开发的情况下，如何有效管理接口的变更和影响，是一个重要的实施挑战。l 成熟模块的适配性：将已有的成熟模块128、与新的架构无缝对接，同时保持开发和测试的效率，是另一个需要解决的问题。4.边界网络节点的支持关键技术：l 多网络协议的兼容性：通信框架需要能够支持多种网络协议，并作为边界网络节点将不同领域的成熟组件无缝对接，确保跨网络、跨领域的数据传输与集成。l 边界节点的动态适应性：实现边界节点的动态配置和适应能力，确保在多种通信协议下能够保持通信的一致性和有效性。中国汽车基础软件发展白皮书 5.0038实施挑战：l 网络协议的复杂性：如何在不同网络协议之间实现无缝转换，并确保通信的实时性和数据完整性，是主要挑战之一。l 统一管理与控制：在实现多网络协议兼容的同时，如何保证系统的整体管理与控制能力不被削弱，129、也是一个需要解决的问题。5.安全与稳定的通信机制关键技术：l 安全通信协议的集成：需要在通信框架中集成安全协议，确保数据在传输过程中的机密性、完整性和真实性，防止非法访问和数据篡改。l 稳定的实时通信：确保通信的实时性和高可用性，特别是在涉及安全关键应用（如自动驾驶）的场景下，需要具备应对各种通信故障的能力。实施挑战：l 安全与性能的平衡：在确保通信安全的同时，如何不影响系统的性能和实时性，是一个关键的平衡点。l 量产阶段的稳定性验证：如何在量产之前充分验证通信框架的稳定性，特别是在大规模并发通信和复杂网络环境下的表现，是一个不可忽视的挑战。4.5 整车通信总线 API整车通信总线针对不同的数130、据来源提供了统一的接口，屏蔽不同的物理总线与通信协议层，对不同的 Channel 做封装，向上层应用提供统一操作语义的接口，通过同一套语义的 API 及配置方式，实现整车不同场景下的数据传递。具体接口信息如表 3.1-2 所示：表3.1-2 整车通信总线API模块接口描述CommonTypeTimer定时器，实现定时任务。PodMessage定义使用内存原始拷贝方式格式化的通信消息类型。RawMessage定义可变长度的通信消息类型。MessageInfo定义消息的其它元数据，如发送时间、接收时间、生成时间等。Executor执行器，提供基础的执行线程环境，用于执行异步消息处理回调、定时器回调131、。Node所有通信对象（如 Reader、Writer 等）、自定义 Timer，都是从 Node创建出来的，并且和Node 关联。TopicWriter消息的发布者。Reader消息的订阅者，当 Writer 发送消息后，Read-er 会收到数据并调用回调。MethodServer实现了服务端的相关功能。Client实现了客户端的相关功能。中国汽车基础软件发展白皮书 5.0039模块接口描述QoSReaderQoS定义了 Reader 端的 QoS 策略。WriterQoS定义了 Writer 端的 QoS 策略。FusionandFilterCacheFusionSynchro-nize132、r实现了基于时间规则的缓存与融合同步。SchedulerPerformanceScheduler高并行调度器，带任务优先级的高并行执行。PersistenceScheduler绑定调度器，任务可以绑定指定的线程；如果任务不指定线程，则通过 Round-Robin 方式绑定到线程。CyclicScheduler周期任务调度器，支持周期任务调度。整车通信总线向上层应用提供了一套和谐一致的 API，其内部对底层通信协议进行了封装，包括TCP/IP 协议、ZeroMQ 协议、DDS 协议、共享内存等。同时为了更方便上层应用的开发整车通信总线使用动态配置方式，当上层应用切换通信协议时，不需要修改任何代码133、，只需要修改相应的配置文件即可。整车通信总线还支持与第三方标准的 DDS 服务和 ZeroMQ 服务进行数据传递。5.整车数据处理框架随着汽车向智能化、电动化和网联化的方向发展，软件和计算能力逐渐成为汽车产业的关键因素。作为一种重要的资源，数据成为未来软件能力的重要创新源泉，数据相关的特性也成为创新业务的新赛道，包括数据集成与融合、云计算与边缘计算的结合、数据安全与隐私保护、数据驱动的智能服务等，因此整车数据相关的需求越来越多，业务逻辑越来复杂，将业务逻辑与数据进行分离的必要性也越来越明确。整车数据处理框架致力于数据与业务逻辑的分离，需要通过统一的视图将数据处理封装起来，从而使得业务逻辑简单化134、，提高开发效率；因此，整车数据处理框架需要提供高性能的数据存取和简单易用的 API 接口，支持数据快照功能和多种序列化策略，实现数据的同步与共享。其核心在于数据变化条件的检测机制和基于数据的动作执行框架，支持分布式共享，并简化了服务应用的开发。该框架通过接口层、核心层和调度层的高效设计，为应用提供稳定可靠的数据服务，同时保证了数据的实时性和一致性。此外，通过与整车通信总线的无缝衔接，该框架实现了数据的分布式共享，进一步增强了系统的灵活性和可扩展性。整车数据包括但不限于以下几个方面：l 车辆基本数据：包括车辆标识数据、车辆属性数据、核心零部件标识数据、车辆鉴别数据、车辆维保数据等。l 感知数据：135、涵盖传感器数据（如激光雷达数据、毫米波雷达数据、摄像头数据等）、地图数据、融合数据等，这些数据通过车载传感器获取并经过处理，用于车辆的感知算法。l 决策数据：包括驾驶员操作数据、远程操作数据和系统决策数据，这些数据对车辆的行驶和操作有直接影响。l 运行数据：涉及整车状态数据、系统及部件状态数据、安全日志数据等，这些数据反映了车辆的实时运行情况。l 其他数据：包括用户身份标识数据、用户与座舱交互数据（非操控类数据）、OTA 数据、V2X数据等，这些数据关联用户交互和车辆通信。5.1 整车数据处理框架的适用场景在现代汽车的快速发展背景下，整车数据处理框架的适用场景日益广泛，支持以下应用场景，包括中136、国汽车基础软件发展白皮书 5.0040但不限于：l 个性化驾驶体验：利用车端底盘、驾驶员等数据信息，结合云端大模型进行训练，优化驾驶感，提供舒适且适合不同驾驶习惯的驾驶体验，还能提高道路交通的安全性和效率。l 智能辅助系统：通过分析驾驶员的行为数据，车辆可以提供更加智能的辅助驾驶功能，如自动泊车、自适应巡航控制等。l 预测性维护：通过车辆的运行数据，预测车辆的维护需求，减少意外故障，提高车辆的可靠性和安全性。l 能源管理：利用车辆的行驶数据和环境数据，优化能源消耗，提高电动汽车的续航里程。整车数据处理框架的适用场景涵盖了从分布式系统的数据同步到大数据应用的基础支撑，从简化应用开发到促进数据融合137、的多个层面。它不仅为现代汽车电子系统提供了强大的数据管理能力，还为汽车行业的技术创新和业务发展开辟了新的道路。通过整车数据处理框架的应用，汽车制造商能够更好地应对市场的快速变化，满足消费者对智能化、网联化汽车的需求。5.2 整车数据处理框架的定义随着汽车新业务的发展和新技术的介入，汽车软件的复杂度大幅增加，业务逻辑越来越复杂，数据协同需求越来越细致，导致汽车软件的体量、耦合性、维护难度都大幅增加。因此，将业务逻辑与数据治理分割开进行处理，标准化数据定义和使用方法，成为汽车软件的下一个解耦关键点。整车数据处理框架就是为了解决“数据与逻辑”分离的问题而提出的，可以提高软件的可维护性、可复用性与稳定138、性。该框架的核心在于构建一个高效、统一、灵活扩展的数据处理界面，使得车辆各系统间的数据能够同步、共享，并且能够按需触发相应的逻辑处理。如图 3.1-5 整车数据处理框架所示，在整车数据处理框架中，数据被视为独立的实体，与具体的业务逻辑相分离。这种分离可以通过一系列功能和机制来实现，如 AUTOSARClassic 标准中的 RTE 框架，它允许应用专注于数据本身，而无需关心数据的接收与发送细节。随着汽车通信技术的发展，整车数据处理框架进一步扩展了其功能，以适应更大的数据量、更多样的协议类型以及动态的通信需求。图3.1-5 整车数据处理框架 整车数据处理框架的关键组成部分包括：l 数据中心：负责139、整车数据的存储、管理和优化，支持快速筛选和服务管理，支持数据快照，实现内存数据到非易失存储的映射，确保了数据的持久性和一致性。中国汽车基础软件发展白皮书 5.0041l 数据采集：提供与不同系统应用通信的接口，支持多种网络协议和数据类型，使得数据能够在整车范围内高效传输。l 数据服务：允许用户配置数据更新、超时和定时触发等通知方式，通过内置的调度引擎和触发式服务，简化了传统服务应用的开发方法。在整车数据处理框架中，数据的分类和分级遵循一系列原则，包括合规性、科学性、实用性、扩展性、时效性和稳定性。数据分级则基于数据的危害性和重要性进行评估，以确定数据的敏感度和保护级别。整车数据处理框架的设计考140、虑到数据存储、数据处理、数据分析、数据安全、实时性、可扩展性、可靠性和开放性等多方面因素。整车数据处理框架的优势在于：l 高性能：采用读写分块、零拷贝、共享内存等关键技术，实现低时延、高吞吐的数据存取，保证了业务数据存取的实时性。l 易用性：API 接口简洁明了，支持多种编程语言，使得开发者能够轻松实现数据的序列化、反序列化以及触发相应的逻辑处理，降低了应用开发的复杂性。l 兼容性与扩展性：能够与不同的消息框架和数据类型定义无缝衔接，支持分布式系统的数据共享，适应了整车级的数据处理需求。总体而言，整车数据处理框架可以为汽车软件开发提供一个强大的基础设施，它通过优化数据管理能力和数据服务，可以促141、进整车电子系统的智能化和网联化，为汽车行业的创新发展奠定坚实的基础。5.3 整车数据处理框架的功能整车数据处理框架旨在构建一个高效、灵活的数据服务中心，以实现数据与逻辑的彻底分离，提升现代软件的可维护性、复用性与安全性。为整车数据的统一处理提供了强有力的支持，确保了数据的高效同步与共享。整车数据处理框架的主要功能如下：l 数据采集：整车数据处理框架能够从车辆的各个传感器和控制器中获取数据，并可以进行降频的数据收集，即抽帧，为上层业务提供遵守合适规则的、真实需要的数据。l 数据存储：管理数据的物理存储和逻辑组织，提供数据存储访问接口。l 数据快照：整车数据处理框架具备实时数据快照的能力，这意味着142、它能够将内存中的数据状态在任何时刻映射到非易失性存储中。这一功能对于故障诊断、系统恢复以及数据记录至关重要。它确保了即使在系统发生故障的情况下，也能够通过快照恢复到故障前的状态，保障了车辆数据的完整性和安全性。l 多种序列化策略：为了适应不同系统、网络协议和开发语言的数据交换需求，整车数据处理框架支持多种序列化策略。这些策略包括但不限于 JSON、XML、协议缓存（Protobuf）等，且用户可以根据具体需求进行配置，以实现最佳的数据共享和传输效率。l 统一的数据处理单元：作为整车数据的统一处理模块，是整车数据处理框架的核心组件。它不仅负责数据的存储、管理和分发，还提供了数据融合、筛选等策略，143、确保了数据的一致性和准确性。l 高性能存取：整车数据处理框架采用了先进的读写分块、零拷贝和共享内存技术，大幅提升了数据存取的性能。这些技术的应用，使得数据存取具有低时延和高吞吐的特点，同时减少了资源占用，非常适合于量产环境。中国汽车基础软件发展白皮书 5.0042l 数据调度引擎：整车数据处理框架的数据调度引擎为用户提供了灵活的配置选项，支持数据更新、数据超时和定时触发等多种通知方式。用户可以利用谓词系统配置复杂的逻辑表达式，并定义自定义命令来执行特定的动作，从而实现高度定制化的数据处理流程。l 数据安全与合规性：实施数据保护措施，确保合规性，并处理数据访问请求和审计，提供数据访问控制、加密、144、脱敏、合规性检查和审计日志接口。由此可见，整车数据处理框架具有如下特点：l 支持分布式系统的数据同步与共享：随着汽车电子系统的复杂性日益增加，分布式异构系统的数据同步与共享成为了一个亟待解决的问题。整车数据处理框架通过提供数据快照功能，实现了内存数据到非易失存储的映射，保证了数据的一致性和可靠性，确保不同系统间的数据实时同步，为整车提供高效的数据服务。l 支持数据与逻辑分离的开发模式：整车数据处理框架推动了数据与逻辑分离的开发模式，这种模式在现代软件开发中至关重要。在传统的 MCU 架构和新兴的以太网总线、SOA 开发方式中，整车数据处理框架能够有效处理动态分配的通信资源，满足多样化的数据传输145、需求。适用于对系统性能和扩展性有极高要求的车辆系统。l 支持高效的数据处理与缓存策略：整车数据处理框架为整车数据提供了高效的处理和缓存策略。它能够根据数据的使用需求，提供多种触发策略，实现数据的高效利用。在自动驾驶、ADAS等实时性要求高的应用场景中，能够确保数据的快速响应和处理，提升系统的整体性能。l 支持面向大数据应用的基础组件：整车数据处理框架作为高性能 Cache 系统，为大数据应用提供了坚实的基础。它不仅支持高性能的数据中心，还提供了高性能的谓词系统，为整车数据服务提供了强大的支持。在车辆健康管理、远程信息处理等大数据应用场景中，整车数据处理框架能够有效支撑数据的采集、存储和分析。l146、 支持多网络协议和数据类型的兼容性：整车数据处理框架具备良好的兼容性，能够支持多种网络协议和数据类型。这使得它能够无缝对接不同的车辆系统，无论是在 CAN 网络、以太网总线还是其他新兴通信协议下，都能够稳定运行。l 促进跨平台和跨系统的数据融合：在整车数据处理框架的支持下，不同平台和系统之间的数据融合变得更加容易。它为开发者提供了一个统一的接口和数据处理机制，使得跨平台的数据集成和融合成为可能。对于提升整车的智能化水平和用户体验具有重要意义。整车数据处理框架作为汽车智能化发展的关键技术，通过其高性能的数据处理和服务能力，为车辆提供了实时、可靠的数据支持。它不仅实现了数据的高效管理，还简化了开发147、流程，提升了系统的集成度和可维护性，为智能驾驶和车辆监控等高级功能奠定了坚实基础，是推动汽车行业向更高效、智能化方向发展的关键平台。5.4 整车数据处理框架 API整车数据处理框架负责收集和存储整车数据，以及数据丢失、错误和延迟处理，实现数据的存储、查询和更新，以维护数据的一致性和完整性。具体接口信息如表 3.1-3 所示：中国汽车基础软件发展白皮书 5.0043表3.1-3 整车数据处理框架API模块接口描述DataCenterOpen表示打开数据库。Close表示关闭数据库。Set表示更新数据库中数据。Get表示从数据库中获取数据。GetHistoryValue表示获取所有历史缓存数据。G148、etPreviousValuesByTime表示从过去的指定时间范围内获取数据。GetFutureValuesByTime表示从未来的指定时间范围内获取数据。GetValuesByTime表示在指定时间范围内获取数据。5.5 整车数据处理框架的关键技术与实施挑战随着智能化推进，整车数据处理框架的角色愈发关键，需准备应对技术进步带来的复杂性与不确定性，确保在动态市场中保持领先，助力汽车行业的持续创新与发展。在探讨整车数据处理框架技术与挑战时，我们既要审视当前技术发展，又要预见汽车行业未来趋势。整车数据处理框架的关键技术：l 软件架构升级：随着汽车行业向软件定义汽车转变，软件架构的升级成为必然。面149、向服务的架构（SOA）方法论的应用，使得汽车硬件能力得以服务化，这不仅提高了资源利用率，还增强了系统的灵活性和可扩展性。通过 SOA 标准化的接口设计，整车数据处理框架能够实现不同服务组件之间的无缝对接，从而提升系统的整体性能和可靠性。l 标准化接口：在整车数据处理框架中，接口标准化是实现跨车型、跨零部件供应商数据共享的关键。通过标准化接口，可以大大减少软件开发过程中的重复工作，降低复杂度，同时确保了不同系统之间的兼容性和可迁移性。l 数据快照能力：数据快照功能为整车数据处理框架提供了内存数据到非易失存储的映射能力，这对于故障诊断、系统恢复以及数据记录至关重要。通过快照功能，可以在任何时刻捕捉150、系统状态，为后续的分析和优化提供宝贵的数据支持。l 高性能存取技术：通过采用读写分块、零拷贝、共享内存等先进技术，整车数据处理框架实现了高性能的数据存取。这些技术降低了数据存取的时延，提高了吞吐量，同时减少了资源占用，非常适合于资源要求苛刻的场景。l 可配置的采集精度：车端数据库应具有高采集精度，支持采集原始频率的信号数据，以确保获取到的数据准确度满足项目需求。支持采集原始数据最小周期 10ms；支持云端可配置采集上传周期，支持自定义数据上传的数据频率。l 数据管理策略：车端数据库应支持数据降频功能，在支持原始频率信号存储和上传的基础上，可按照业务部门实际需求自定义指定信号和频率上传，实现最小151、数据量回传/按需回传策略。整车数据处理框架的实施挑战：l 技术架构挑战：随着汽车电子电气架构的复杂化，软硬件数量的增加，任何部件的增加、修改、更新都会对整车产生影响。未来的整车软硬件数量可能增加 10 倍以上，这将带来巨大的挑战。为了应对这一挑战，整车数据处理框架需要具备高度的灵活性和可扩展性，以适应不断变化的中国汽车基础软件发展白皮书 5.0044技术需求。l 安全和隐私保护挑战：汽车行业的快速发展也带来了安全和隐私保护的挑战。测试时间长、代价高，安全漏洞可能导致品牌和用户粘性受损。整车数据处理框架需要采取有效的安全措施，包括数据加密、访问控制和异常检测等，以确保数据的安全性和隐私性。l 组152、织流程挑战：整车厂需要建立适应新架构的组织流程，以支持敏捷开发和接口测试。这意味着需要对现有的开发流程进行重构，以适应快速变化的软件需求。此外，组织内部需要建立跨部门的合作机制，以确保整车数据处理框架的顺利实施。l 生态协同挑战：软件定义汽车的发展需要上下游企业的协同合作，包括软件公司、硬件供应商和整车企业。整车数据处理框架需要与这些企业建立紧密的合作关系，以确保数据的一致性和互操作性。同时，整车数据处理框架还需要与行业标准和组织合作，以推动整个行业的协同发展。l 数据孤岛问题：因车端数据来源广泛，不同数据源之间可能存在信息孤岛，导致数据整合和分析的难度增加。因此需要通过建立统一的数据平台和数153、据交换标准，打破数据孤岛，实现数据的整合和流通。此外，利用先进的数据集成和融合技术，提高数据处理的效率和准确性，比如SOA 架构就是典型的解决数据孤岛的解决方案。l 数据出境安全管理挑战：智能网联汽车收集的数据可能包含敏感的地理和个人信息，数据出境时需要符合严格的安全评估和监管要求。因此在向境外提供数据时，应当通过国家网信部门组织的数据出境安全评估，并在评估通过的基础上，确保数据出境活动符合评估时确定的目的、范围、方式和数据类型。同时，监督接收方按约定使用数据，并处理用户投诉。综上所述，整车数据处理框架的实施挑战是多方面的，涉及技术架构、安全性和生态协同等多个方面。为了应对这些挑战，需要整车厂154、和合作伙伴共同努力，建立一个高效、安全、协同的生态系统。这不仅需要技术创新，也需要组织流程的优化和行业合作的加强。只有这样，才能确保整车数据处理框架的成功实施，推动汽车行业的持续发展。（二）AI 大模型与中间件AI 与车端基础类库的结合是智能网联汽车（ICV）和自动驾驶技术发展的关键组成部分。从 AI 视角来看，车是一系列数据与执行器的结合体，车端需要提供给 AI 的是运行数据、控制器与网络拓扑的抽象模型，AI 基于这些抽象元素进行分析、预测和决策。这个过程中，需要车端提供一系列的基础类库，来为AI 开发和运行提供基础功能支持，基础类库包括整车分布式异构架构下车端的通信抽象、数据抽象、车辆基础155、服务，以及与车辆系统隔离开来的 AI 基础服务层。随着 AI 技术和 AI 应用的不断发挥在那，我们可以期待更多、更高效、更强大的车端基础类库的出现，进一步推动智能网联汽车的发展，并反哺推动人工智能更全面、更完善的演进趋势。1.AI 大模型技术对中间件的影响AI 大模型技术对中间件提出了更高的性能要求，但同步也推进了中间件智能化的发展。l 数据处理能力：随着 AI 大模型在汽车中的应用，数据量呈指数级增长。汽车中间件需要具备更强的大数据处理能力，以确保能够快速、准确地传输和处理 AI 大模型所需的数据。例如，自动驾驶场景下，大量的传感器数据需要实时传输给 AI 大模型进行分析，中间件如果处理速156、度跟不上，就会影响驾驶安全和决策的及时性。l 兼容性需求：AI 大模型可能不断更新算法和功能，汽车中间件需要具备更好的兼容性，以适中国汽车基础软件发展白皮书 5.0045应不同版本的 AI 大模型与汽车不同硬件和软件系统的对接。比如，当 AI 大模型从一个版本升级到另一个版本，中间件要能够保证与新的 AI 大模型以及汽车上原有的其他系统（如车载娱乐系统、车辆控制系统等）继续正常协作。l 自适应功能：AI 大模型的智能化特性促使汽车中间件向智能化方向发展。中间件需要能够根据汽车的运行状态、用户需求以及 AI 大模型的输出自动调整数据传输策略、优化系统资源分配等。例如，当车辆处于高速行驶状态时，中157、间件根据 AI 大模型对路况的分析结果，自动调整数据传输优先级，优先保障与安全相关的数据传输到 AI 大模型进行分析处理。l 故障诊断与预测能力：借助 AI 大模型强大的数据分析能力，汽车中间件可以增加故障诊断和预测功能。中间件能够收集汽车各个部件的数据，通过 AI 大模型进行分析，提前发现潜在故障风险，并及时通知车主或相关维修人员。例如，通过对发动机运行数据的长期监测和分析，中间件在 AI 大模型的支持下，可以提前预测发动机可能出现的故障，提高汽车的安全性和可靠性。2.基于大模型的中间件l 从模块化到服务化：随着 AI 大模型的广泛应用，传统基于功能模块的软件架构正逐渐向服务化转变。服务化架158、构支持跨功能的集成，车辆的各项功能通过 API 接口形成服务网络，不同功能之间共享数据和逻辑，使得从而实现更为复杂和智能化的服务组合，使其更符合 AI 应用的动态性和数据驱动特性，使车辆能够根据实际需求快速调整其行为，同时提高软件的灵活性和可扩展性。例如，通过集成车辆健康监测、故障预测和维修服务，可以为车主提供一站式的车辆健康管理解决方案，简化软件维护，使得开发者能够更加专注于创造新的价值。l 引入 AI 服务层：在软件定义汽车的基础上，AI 边缘计算与 AI 服务层的引入使得车辆能够实时处理复杂的数据流，实现智能决策。AI 服务层作为连接底层硬件和上层应用的重要桥梁，能够提供更加个性化和安全159、的驾驶体验，还能为用户提供诸如自动泊车、智能导航等高级功能。AI服务层还可以支持车辆与其他车辆或基础设施之间的互联互通，为实现车联网和智慧城市奠定基础。l 生成式开发与自适应系统：生成式开发要求软件架构具有高度的灵活性和可配置性，自适应系统根据车辆的实际运行情况和外部环境的变化快速迭代和自我优化。例如，如果检测到车辆的电池电量低，自适应系统可能会自动调整能量管理策略，延长续航里程。这种自适应机制可以提升用户体验，车辆安全性和可靠性。随着更多的数据积累和 AI 算法的不断优化，自适应系统的性能将进一步提高，为用户提供更加智能化和个性化的服务。3.AI Agent 基础服务层车端 Agent 是运160、行在车辆内部的 AI 智能体，它负责感知来自车身、云端以及外部环境一系列与车辆操作、监控、诊断和通信等相关的任务，并不断推理、监控、反馈、学习，最终能够在没有外界直接操纵的情况下作出决策并执行任务。如果说车端基础功能层为车端 Agent 能够实时、准确、高效地获得数据提供了保证，那么 Agent 基础服务层则提供了 AI 上车的技术底座，不仅对上层的 AI 应用开发提供框架支持，还通过下层 SOVD 等接口实现对车端行为的管控。如图 3.2-1AIAgent 所示，Agent 基础服务层的功能应该包含但不限于以下方面：（1）感知模块（Perception）：具备对多模态的感知和执行动作的理解/161、监控的能力。其中 Mul-ti-ModelFusion 功能可以将用户数据、车身数据、传感器数据、环境数据等信息整合到同一个上下文中，中国汽车基础软件发展白皮书 5.0046以任务的方式发送给规划模块；ActionAwareness 可以将动作执行的结果信息反馈给规划模块的反思功能（见下文）。（2）规划模块（Plan）：具备任务分解及调度、结果跟踪、知识整理和推理优化的能力。其中 Rea-soning&DC 负责与记忆模块交互进行逻辑思考、分析和推断，以及对具体的任务进行分治处理；Task 负责任务管理，监控任务调度及任务优先级管理；Reflection 负责与执行模块交互，根据历史经验进行知162、识整理和推理优化，这些知识的来源包含用户参与的反馈信息，以及执行结果评估后的反馈信息。（3）记忆模块（Memory）：备知识及经验的整理及检索、记忆及知识管理的能力。RAG 负责对知识与经验进行整理和检索，并根据每个任务目标对知识库中的相关信息进行整合，生成合适的提示信息发送给 PromptsEngine；PromptsEngine 是提示引擎，负责根据不同的任务构建更精准的提示信息并反馈给执行模块；Knowledge/Memory 则负责对知识的读写和知识库管理。（4）执行模块（Action）：具备执行任务和评估执行结果的能力。ExecutionEngine 是动作执行引擎，负责执行离散指令163、和连续指令，同时内嵌 WebService 框架，可以执行来自 Tools 及云端的指令；Assessment 负责对执行结果进行评估，形成一条执行经验，并反馈给规划模块进行反思。图3.2-1 AI Agent4.AI 大模型与中间件结合的发展趋势AI 大模型技术与汽车中间件结合的发展趋势主要体现在以下几个方面：l 智能化应用：未来中间件将更加依赖 AI 大模型，实现更高级的智能化功能，如自动驾驶、车载语音助手和个性化服务。l 数据融合与分析：中间件将加强与多种传感器的数据融合能力，利用 AI 进行实时数据分析，从而提升决策准确性和响应速度。l 边缘计算：随着对实时性的需求增加，更多计算将在车164、辆边缘进行，减少延迟并提高数据处理效率。l 安全性提升：AI 将帮助中间件实时监控系统安全，预测并防止潜在的安全威胁。l 生态系统整合：中间件将与云服务、物联网和其他智能设备深度整合，形成更加复杂和互联的汽车生态系统。这些趋势将推动汽车中间件向更智能、高效和安全的方向发展。中国汽车基础软件发展白皮书 5.0047四、开放式软件架构的操作系统底座开放式软件架构的操作系统对下驱动硬件资源、对上承接中间件，通过模块化设计、标准化接口、虚拟化技术以及 AI 包括大模型的应用，实现了软硬件的深度一体化和软软、软硬解耦以及多平台兼容和 AI能力的动态扩展。本章节将围绕操作系统、安全和 AI 融合，对开放式165、软件架构的操作系统底座作详细介绍。（一）开放式软件架构下的操作系统如图 4.1-1 面向 AI 的开放式软件架构的操作系统底座所示，开放架构不仅为第三方应用、服务和中间件的生态开发提供了强有力的支持，还通过增强的安全性、稳定性、实时性以及大模型赋能的智能化功能，进一步推动了系统的演进和创新。同时，软硬一体化的设计理念与大模型技术的结合，使得操作系统能够更高效地调度和利用异构计算资源，为智能驾驶、座舱和智能车控提供更强大的智能开放生态底座支持。图4.1-1 面向AI的开放架构操作系统底座1 软硬一体域控制器正从单一功能的域内集成演化至多功能的域间集成。这种转变不仅提高了系统的集成度和智能化水平，166、还带来了计算资源的配置和安全性方面的挑战和需求，芯片的归一化趋势越来越明显。1.1 技术特性芯片归一化是指：对计算芯片的规格进行归一。归一化的芯片设计能够统一处理不同功能域（如动力控制、自动驾驶、车载娱乐等）的任务，简化控制器的系统设计和集成。电子电气结构的中央集中趋势也推动了芯片设计的归一化，以支持跨域任务的协同处理。高集成度的系统级芯片（SoC）正逐渐成为主中国汽车基础软件发展白皮书 5.0048流，集成了计算、存储、通信、安全等多个功能模块，能够支持更复杂的计算任务和更高的安全需求。当前，多家主流汽车芯片公司纷纷推出自己的多域融合高性能 SoC 芯片。基于一颗芯片实现舱驾控等多域融合，对167、操作系统提出了很大的挑战：l 系统稳定性与实时性的挑战：同时满足智驾和车控的实时性与可靠性要求以及座舱的多任务处理和复杂用户体验的响应，需要操作系统具备高效的调度、资源管理能力和有效的隔离机制。l 安全性的挑战：智驾域的安全关键任务不受座舱域复杂应用的干扰，需要更高效的虚拟化技术和强健的隔离机制。l 性能优化的挑战：操作系统设计必须充分利用单芯片的多核、多线程及异构计算资源（如CPU、GPU、NPU 等），以同时满足多域的高性能需求。为应对以上挑战，操作系统将在异构计算、实时和非实时任务的调度优化以及内存与 I/O 管理这几个方面持续优化，以提高系统的可靠性与稳定性，提升软硬融合的效率和质量软168、硬协同背景下，操作系统在芯片归一化中扮演着重要角色。操作系统作为控制器的核心，需要通过建立车内计算资源池，以高效的资源管理和调度策略灵活地分配计算资源，满足不同场景需求。此外，软硬件平台之间需要深入协作和通信，操作系统要提供一套统一的标准与 API，通过 API 将硬件能力抽象化，使上层应用可以不受硬件差异的影响，从而简化应用开发，屏蔽底层实现，提升软硬件协同开发效率。为满足信息安全与功能安全的需求，操作系统还需要支持虚拟隔离和容器技术，以保证不同的应用在独立的容器内可以正常运行。芯片设计上，为实现计算资源的有效整合，克服当前面临的挑战，行业需要在更高层次上对计算资源进行抽象，如计算任务的细粒169、度管理，将复杂的计算需求分解成更小、更标准化的任务单元，以便能够在统一的硬件平台上高效处理，使软件能够无缝地与硬件交互，隐藏硬件之间的差异。硬件与软件的协同设计是提升系统性能和可靠性的关键。具体措施包括：为关键算法提供硬件加速，如 AI 推理、图像处理等，减少软件层的计算负担，提高整体系统效率。通过软件优化硬件的使用模式，如动态电压和频率调节（DVFS），在保证性能的前提下降低功耗。提供硬件和软件一体化的开发工具和软件开发工具包（SoftwareDevelopmentKit，简称 SDK），简化开发流程，缩短产品上市时间。通过实时监控系统的硬件使用情况，动态调整软件的运行策略，以适应当前的硬件170、状态和外部环境变化。这些措施能够确保在多域融合的复杂系统中，软硬件能够协同工作，达到性能最优、安全性最强的系统设计目标。1.2 挑战与对策在架构层面上，芯片厂商往往有自己独特的定义与实现，这导致底层软件的 Pin2Pin 复用变得极为困难。尽管操作系统通过提供丰富的标准化设备模型来隐藏硬件实现细节的差异，让软件开发者可以在更高层次使用硬件功能，但底层软件的重构常因片上系统的定制化差异而充满挑战，开发过程很难脱离原厂的技术支持，使软件与芯片的深度耦合，在这样的背景下难以实现一次开发、多次复用的目标，行业的整体开发效率受到影响。以车用 SoC 为例，SoC 往往集成一些大型 IP，如 CPU、GP171、U、视频编解码等，相对应用稳定，接口生态较为完整，使得相关开发者可以通过公开的生态接口进行编程。然而，针对一些定制化的数据通路和基础控制问题，常与芯片的硬件设计紧密相关，如系统的信息安全架构、内存架构和电源管理等，在芯片设计初期由芯片公司的系统工程师（SE）以较私有实现的方式定义。这种做法使得第三方公司难以直接使用开发接口，标准化的难度也极高，系统的碎片化严重。而在实施标准化过程中，由于芯片的性能中国汽车基础软件发展白皮书 5.0049要求和物理参数限制等，往往阻碍了统一接口的实现。AUTOSARCP 为解决这些困难提供了参考思路，通过接口进一步下移，实现对 MCU 芯片底层的抽象，定义出芯片172、模型和底层的硬件/OS 无关性接口，进而使行业相关方得以在统一的接口下协同工作。然而车用芯片的发展速度快，集成度与电路规模越来越大，标准的发展往往与行业实际的发展步调不统一，使得软硬件之间的适配依然很难协调进行。尽管如此，产业界对缩短开发周期、降低成本的强烈需求也成为驱动芯片厂商与基础软件厂商共同定义和实现统一接口的动力，通过进一步解耦底层软件与芯片，实现一次适配多芯片复用，提升行业的开发效率。这需要在共识、标准的制定以及生态建设方面发力，行业的领导厂商需共同推广开发标准，对SoC 架构和非标件等差异化部分进行标准约束，加强芯片原厂与软件厂商甚至 IP 厂商的协同合作，定义与操作系统无关的硬件173、抽象层（HardwareAbstractionLayer，以下简称：HAL），减少底层软件与硬件之间的直接依赖，隐藏芯片设计细节，使第三方开发者能通过更底层的 HAL 接口与硬件交互。2 虚拟化虚拟化（Hypervisor）也称为 VMM（VirtualMachineMonitor，虚拟机监视器，以下简称：Hyper-visor），是一种运行在物理服务器和虚拟机系统之间的中间软件层，可允许多个虚拟机共享一套物理基础设施。当 Hypervisor 被启动并执行时，会为虚拟机分配 CPU、内存、磁盘、网络等硬件资源，并加载虚拟机的客户操作系统。随着人工智能技术的发展，特别是大规模预训练模型的兴起，174、对计算资源的需求日益增加。与此同时，为了提高资源利用效率和系统灵活性，虚拟化技术在面向 AI 大模型的开放式软件架构中发挥了关键作用。如图 4.1-2 虚拟化基座接口所示，虚拟化技术通过将物理资源抽象为逻辑资源，允许在同一物理基础设施上创建多个独立的虚拟环境。虚拟化技术通过将不同的资源进行隔离，从而实现不同虚拟环境上资源的独立，避免不同的虚拟环境故障的相互干扰。在资源隔离的基础上，虚拟化技术也可以实现资源的共享，从而提高资源的利用率。虚拟化技术提高了系统的灵活性。灵活性体现在允许不同形式的应用部署，以及允许应用重建和重新部署。虚拟化技术通过提供虚拟环境，允许不同特性的应用按需求部署，包括实时性175、应用、非实时性应用、功能安全应用以及非安全应用。通过允许虚拟环境的创建、销毁、复制、甚至迁移，从而在部分功能故障的情况，可以实现系统功能的快速重建，以及重新部署，提供系统的可用性、安全行及灵活性。虚拟化技术提高系统的可移植性。灵活的虚拟环境支持不同的操作系统的部署，包括但不限于实时操作系统、多样性操作系统，如 SafetyLinux、Android、其他 RTOS 功能安全操作系统等等。多样的环境为已有的软件提供了便捷的移植环境。虚拟化技术为 AI 应用的部署提供了基础，隔离性使得 AI 应用与其他应用，如关键的控制应用避免相互影响。灵活性和可移植性为 AI 应用提供便捷的部署方式。实时操作系176、统提供了第一手的数据及实时响应的部署环境。Linux 则提供了更完整的生态和无需修改的部署环境。中国汽车基础软件发展白皮书 5.0050图4.1-2 虚拟化基座接口2.1 技术特性（1）虚拟化构成如图 4.1-3 虚拟化架构所示，虚拟化的架构主要分为两种：l 裸机型 Hypervisor裸机型（也被称为 Type1 型），是指 Hypervisor 运行在物理服务器上，GuestOS 对硬件的访问必须通过 Hypervisor 完成。Hypervisor 作为底层硬件的直接操作者，拥有硬件的驱动程序，可以直接管理和调用硬件资源。l 宿主型 Hypervisor宿主型（也被称为 Type2 型）177、是指 Hypervisor 之下还有一层宿主操作系统，GuestOS 对硬件的访问必须经过宿主操作系统。虚拟机上的应用程序调用硬件资源需要经过多层（VM 内核 Hypervisor 主机内核），但可以充分利用宿主操作系统提供设备驱动和底层服务来进行内存管理、进程调度和资源管理等。图4.1-3 虚拟化架构中国汽车基础软件发展白皮书 5.0051由于宿主型 Hypervisor 性能较低和开源生态优势等原因，目前在车端场景主要采用 Type-1 型架构的计算虚拟化。其中计算虚拟化对物理资源的虚拟可分为 CPU 虚拟化、内存虚拟化和 I/O 虚拟化，实现方式可分为全虚拟化、半虚拟化和硬件辅助虚拟化：178、1）CPU 虚拟化实现虚拟化的经典方式是使用“特权解除、陷入模拟”，即将 Hypervisor 运行在最高特权，GuestOS 运行在非特权级。解除 GuestOS 的特权级后，大部分指令仍然可以直接在硬件上运行，只有执行特权指令时，才会陷入到 Hypervisor 模拟执行。具体实现方式包括 CPU 全虚拟化、CPU 半虚拟化、CPU硬件辅助虚拟化。当前，主流架构（如 ARM 架构，X86 架构等）的 SoC 芯片均支持 CPU 硬件辅助虚拟化，同时该方式也是虚拟化效率较高的一种方式。2）内存虚拟化虚拟内存是一种计算机系统内存管理机制，可以将物理内存抽象化，为应用程序提供连续的虚拟内存地址（179、64 位系统地址空间为 264）。系统将虚拟地址空间和物理地址空间分别划分为大小相同的页，并通过页表记录地址之间的映射关系，MMU（内存管理单元）根据页表完成虚拟地址到物理地址的转换。在计算虚拟化中，Hypervisor 管理系统的内存资源，虚拟机也有内存管理机制，因此有 VA（客户机虚拟地址）、PA（客户机物理地址）、MA（宿主机机器地址）三层映射关系，而内存虚拟化需要完成 VA到 MA 的转换。就实现方式而言，内存虚拟化也包括内存全虚拟化、内存半虚拟化、内存硬件辅助虚拟化等方式。其中，硬件辅助虚拟化的效率较高。3）I/O 虚拟化从 CPU 的角度来看，外设是通过一组 I/O 资源访问的设备180、，因此设备相关的虚拟化被称为 I/O 虚拟化。Hypervisor 通过 I/O 虚拟化来复用有限的设备资源，包括显卡、网卡和硬盘等。I/O 虚拟化包括全虚拟化、半虚拟化、硬件辅助虚拟化。其中 I/O 半虚拟化相关技术包括 VirtIO 虚拟化框架，是当前车端外设虚拟化的主流技术之一，对于 GPU/NPU 等高速外设，基于硬件辅助虚拟化也是比较常见的虚拟化技术，可以获得较高的虚拟化效率保证。（2）虚拟化性能虚拟化损耗是指在虚拟化环境中，由于虚拟化层（如 Hypervisor）对物理资源的抽象和管理，导致虚拟机（VM）在运行应用程序时相对于裸机环境所表现出的性能下降。这种性能下降可能涉及 CPU181、、内存、I/O、网络等多个方面。对于 CPU 而言，当前主流架构的 CPU 均支持硬件辅助虚拟化技术，可以有效降低因为虚拟化带来的性能损耗，通常而言可以控制到 1%左右的损耗比。当然，这里虚拟化性能损耗和实际的系统运行负荷也有一定的关系，如频繁的上下文切换和调度，一定程度上会加剧 CPU 虚拟化损耗。对于内存而言，当前主流硬件均支持硬件辅助虚拟，可以实现较低的内存虚拟化性能损耗，通常可以控制到 2%以下。对于 I/O 外设而言，其类型多种多样，有高速设备也有低速设备，对应可采取的虚拟化技术有多种：时间分片复用方式，Passthrough 方式，VirtIO 半虚拟化方式，硬件辅助虚拟化（如基于182、 IOMMU 技术）。其中时间分片复用方式的虚拟化，需要硬件驱动和 hypervisor 密切配合，实现复杂度高，可以获得较高的虚拟化性能。Passthrough 是透传模式，主要场景是外设对于某个特定 VM 的专属访问，可以实现接近硬件的虚拟化性能，但是不利于多个 VM 之间的设备共享。VirtIO 半虚拟化方式基于标准化的 VirtIO 框架，中国汽车基础软件发展白皮书 5.0052有利于外设虚拟化的前后端解耦，但是这种方式的虚拟化损耗通常比较高（如 10%以上），通常用于低速设备的 I/O 虚拟化。硬件辅助虚拟化需要专门的硬件支持，可以实现较高的虚拟化性能。（3）虚拟化安全虚拟化相关的安183、全包括功能安全和信息安全等方面。其中，对于功能安全而言，虚拟化作为底层 OS的重要组成部分，既包括自身功能安全特性和要求，也包括和车端软硬件其他部分的协同，共同实现整体功能安全目标与要求（SafetyGoal）。对于 Hypervisor 自身功能安全要求，需要按 ISO26262（道路车辆功能安全）规范的相关要求进行系统设计、开发、测试与验证等全生命周期的研发活动，并实现相关的功能安全等级认证（如 ASILB/D）。此外，虚拟化 Hypervisor 还可以和其他系统协同，实现系统整体的功能安全特性提升。如图 4.1-4多层监视框架所示，在智驾场景中基于 SafetyLinux 的软件架构是184、当前相对主流的技术选型，参考 E-GAS（StandardizedE-GasMonitoringConceptforGasolineandDieselEngineControlUnits，由奥迪、BMW、戴姆勒等国际顶尖公司联合起草制定的 ECU 软件架构）安全模型架构，基于 Hypervisor 构建多级监控框架，以此提升系统的功能安全特性，具体如下图所示。图4.1-4 多层监视框架对于车端信息安全，虚拟化 Hypervisor 同样发挥重要作用。首先，基于 Hypervisor 的智驾、座舱、多域融合解决方案场景下，不同虚拟机之间可以很好地实现时空隔离与资源访问控制，一定程度上可保证整个系185、统的信息安全。此外，如图 4.1-5 虚拟化信息安全方案所示，在虚拟化 Hypervisor 中实现特定的安全访问代理，同时与 TEE（TrustExecutionEnvironment 可信执行环境，以下简称 TEE）OS 配合也可以实现控制器系统与外部其他系统之间的信息安全隔离和访问控制，进一步提升车端信息安全。中国汽车基础软件发展白皮书 5.0053图4.1-5虚拟化信息安全方案具体说明如下：（1）非安全虚拟机通过 TEE 虚拟前端驱动调用安全功能，避免直接 SMC（SecureMonitorCall，从非安全世界(NormalWorld)转移到安全世界(SecureWorld)的机制）186、调用带来安全风险；（2）安全虚拟机提供 TEE 虚拟后端驱动，管控各 NEE（Non-secureExecutionEnvironment，非安全执行环境）调用安全功能策略；（3）TEE 系统运行于安全世界（SecureWorld），响应非安全世界（NormalWorld）发起的安全请求；（4）SecureMCU：负责响应硬件安全要求更高的安全请求，SEE（SecureExecutionEnvironment,安全执行环境）或者 TEE 会通过硬件专用 IPC（Inter-ProcessorCommunication，进程间通信）通道转发到 SecureMCU；2.2 演化趋势随着舱驾融合、智187、能底盘的演进，虚拟化将扩展其 CPU 架构支持，支持更多类型的业务融合，典型如实时控制任务、AI 异构算力共享任务等，潜在发展技术路线如下：（1）MCU 虚拟化MCU 在保证实时性、可靠性的基础上，正在持续提升算力，以支持部署更复杂的业务功能，同时也在探索硬件虚拟化能力，以支持多运行环境，确保相互之间充分隔离、免于干扰。比如英飞凌的 Tricore1.8 相对于 1.6 的关键增强包括：CPU 主频从 300MHz 提高到 500Hz，更大更快地内存访问；有 6 个CPU，每一个核可以执行 8 个虚拟机，有专属或者共享的寄存器资源，可通过专属资源实现实时虚拟机，也可以通过共享硬件资源实现更多业188、务系统的并行共享运行。提供内存虚拟化的两级 MPU 保护，基于PRTO/APU(AccessProtectionUnits)外设保护机制实现外设虚拟化，支持用户模式和特权模式等。同时，为实现底盘智能化，需要 MCU 集成相应的 AI 算力。在 AIOT(ArtificialIntelligence&Inter-netofThings)领域，已经有 MCU+AI+SRAM 的技术架构，运行小模型 AI，比如基于 TensorflowMi-croLite 的小语音模型，能跑在几百 KB 到几 MB 的 SRAM 里面。在汽车底盘域中，MCU 可以继续发挥CPU 架构的严格多发射控制、很短的内部总线189、和中断传输通路，以及 SRAM 低延时、低功耗机制，保证中国汽车基础软件发展白皮书 5.0054ASIL-D 安全可靠性，同时逐步集成、拓展 AI 算力，支持在底盘部署嵌入式 AI 推理应用。如图 4.1-6 所示，基于虚拟化支持 MCU 融合的系统架构如下图：图4.1-6 基于虚拟化支持MCU融合的系统架构MCU 芯片架构更加特殊化，各厂商往往有自己的技术路线，当然，业界也有往 ARM、RISC-V 聚合的发展趋势。相对于云计算、SOC 系统，短期内 MCU 上的虚拟化系统更难通用化，需要紧密结合 MCU芯片架构，来实现 CPU、内存、NPU、外设资源的虚拟化。因此，也希望能推动 MCU 芯190、片领域尽快形成共识的技术路线、标准规范，减少虚拟化开发适配工作量。（2）SoC 融合 MCU 功能SoC 芯片越来越重视车规级安全，目前已可支持芯片级 ASIL-B、系统级 ASIL-D。舱驾控一体趋势下，越来越多的功能融合到一个 SoC 上，因此也存在着智能底盘与舱驾完全融合的演进可能性。SoC 已可以将 APU 应用处理器、MCU 微控制器集成在一起，分别承担不同安全等级、业务特性的功能，相互之间通过高性能、高确定性的片上通信协同工作；同时业界也在研究基于 A 核来运行强实时、高可靠、高安全业务的可行性，比如底盘控制、动力总成等。A 核融合 MCU 业务的难点主要在于复杂系统的稳定性、多指191、令及中断执行的确定性、内存访问的确定性等，一方面依赖于芯片技术的进步，另一方面可结合虚拟化的资源分配及管理技术。比如对于关键业务在编译时锁定指令发射机制，虚拟化为关键业务虚拟机锁定分配中断资源、SRAM 内存资源，以保证时延确定性。如图 4.1-7 所示，基于虚拟化支持 SoC 融合的系统架构如下图：图4.1-7 基于虚拟化支持SoC融合的系统架构中国汽车基础软件发展白皮书 5.0055虚拟化根据底盘、动力总成的业务需求，为其分配独立锁定 CPU 资源(比如大小核中的小核)，分配确定的 NPUAI 算力资源，同时分配实时性、确定性更好的 SRAM 内存资源，以满足高功能安全等级要求。外设资源方192、面可以提供 PassThrough 直通，或者共享复用的虚拟化方式。虚拟化技术在面向 AI 大模型的开放式软件架构中扮演着越来越重要的角色。随着技术的不断进步，虚拟化技术将继续为 AI 应用提供更强有力的支持，推动 AI 技术朝着更高效、更安全和更智能的方向发展。3 实时操作系统实时操作系统（RealTimeOperateSystem，简称 RTOS）是汽车智能化和电子控制单元（ECU）功能实现的关键技术之一。如图 4.1-8 实时操作系统所示，它主要负责支撑并管理整车应用程序的任务调度和资源管理，包括但不限于车辆控制、多媒体播放、智能应用等，确保这些应用程序能够安全、高效地运行。随着汽车向电193、动化、智能化发展，电子电气架构正从传统分布式架构向域集中式架构以及中央计算架构转变，车用操作系统技术成为汽车软件生态的重要基础。3.1 技术特性车用实时操作系统的技术重点主要围绕以下几个关键领域展开，旨在满足汽车行业对高性能、安全性、可靠性和实时性的严格要求。图4.1-8 实时操作系统（1）确定性与低延迟l 任务调度的确定性：车用 RTOS 必须具备严格的任务调度能力，以确保关键任务（如制动、转向等）能够在严格的时间限制内执行。确定性调度意味着系统在任何时候都可以预测任务的执行顺序和时间，避免因任务冲突或资源竞争导致的延迟。l 低延迟响应：车用 RTOS 需要在极低的延迟下响应外部事件，如传感194、器输入或用户指令。低延迟对于实现诸如防撞系统、紧急制动等安全关键功能至关重要。（2）安全性与可靠性l 内存保护与任务隔离：RTOS 需要提供强大的内存保护机制，确保各个任务之间相互隔离，防止非授权任务访问其他任务的内存空间。这对于防止软件故障传播，维持系统稳定性和安全性至关重要。l 故障检测与恢复机制：为了提高系统的可靠性，RTOS 通常集成故障检测机制，如看门狗定时器，来监控系统运行状态，并在检测到异常时进行自动恢复或安全降级处理。中国汽车基础软件发展白皮书 5.0056（3）实时通信与同步l 时间敏感网络（TSN）支持：随着车内网络复杂性的增加，RTOS 需要支持时间敏感网络（TSN）技术195、，以确保不同系统组件之间的实时数据传输和同步。TSN 通过时间分片和优先级调度，保证关键数据包能够在严格的时间窗口内传输完毕。l 同步协议与多核支持：对于多核处理器，RTOS 需要实现高效的任务同步和跨核通信，以最大化系统性能，同时避免由于任务竞争而引发的资源争用问题。（4）功能安全与认证l 道路车辆功能安全 ISO26262 认证：车载 RTOS 通常需要符合 ISO26262 功能安全标准，特别是在 ASIL（汽车安全完整性等级）等级较高的应用中。这意味着 RTOS 需要通过严格的安全认证流程，并提供符合功能安全要求的架构设计、开发流程和测试验证手段。l 安全关键任务管理：RTOS 需要支196、持对安全关键任务的优先处理和保护机制，确保这些任务能够在系统发生故障时保持稳定运行，或在必要时优雅降级。（5）资源管理与优化l 动态内存管理：由于车载环境的特殊性，RTOS 必须有效管理有限的内存资源，避免内存泄漏或碎片化。这通常通过静态内存分配或严格的动态内存管理策略来实现。l 功耗管理：随着汽车电子系统的复杂性增加，RTOS 还需要支持高效的功耗管理，特别是在电动车辆中。RTOS 应能动态调整系统的工作频率和电源状态，以在不影响性能的情况下最大限度地减少能耗。（6）虚拟化与多域整合l 虚拟化技术支持：现代车载系统通常需要整合多个功能域，而虚拟化技术可以有效隔离这些功能域。RTOS 需要支持197、虚拟化，以确保不同域之间的安全隔离和资源共享，避免相互干扰。l 多域系统的实时性保障：在多域融合的环境下，RTOS 需要保证每个域内的实时任务能够得到及时调度和处理，即使在资源共享的情况下，也不能影响关键任务的实时性。（7）可扩展性与兼容性l 模块化设计：为适应不同车型和应用的需求，RTOS 通常采用模块化设计，允许根据具体需求定制不同的功能模块。这种设计能够提高系统的灵活性和可扩展性。l 标准接口与兼容性：车用 RTOS 需要与多种硬件平台、传感器和执行器兼容，并支持 POSIX等标准接口，以确保与第三方软件库和工具的兼容性，提高开发效率。（8）实时更新与维护l OTA（Over-the-A198、ir）更新：随着汽车电子系统的复杂化和联网化需求的增加，RTOS 需要支持 OTA 更新功能，允许在不影响车辆正常运行的情况下进行系统更新和维护。l 安全补丁管理：RTOS 还需具备快速部署安全补丁的能力，以应对新出现的安全威胁，确保系统在整个生命周期内的安全性和稳定性。车用实时操作系统的技术重点在于通过高性能的实时调度、安全可靠的系统设计和灵活的资源管理来保障车辆的安全性和稳定性。随着自动驾驶和智能网联技术的发展，车载 RTOS 的功能和性能要求将继续提升，需要不断适应新的技术趋势和应用需求。3.2 演化趋势车用实时操作系统（RTOS）的未来技术演进将受到汽车行业不断发展的需求推动，特别是在199、自动驾中国汽车基础软件发展白皮书 5.0057驶、智能网联、功能安全和能源管理等方面。以下是关键的演进趋势：（1）高性能计算与高级传感器融合l 高性能异构计算支持：随着自动驾驶技术向 L3、L4 级别发展，RTOS 需要更强的计算能力和实时性，将进一步支持异构计算架构，结合 CPU、GPU、AI 加速器等多种资源，满足自动驾驶任务的高计算需求。l 高级传感器融合：RTOS 将处理来自激光雷达、摄像头、雷达等多种传感器的数据，使用更复杂的算法和更高的数据带宽来实时融合信息，生成精确的环境模型。（2）功能安全与信息安全l 多层次安全架构：RTOS 将集成从硬件安全模块（HSM）到软件隔离的多层次安200、全机制，以应对潜在的网络攻击和系统故障。l 安全认证与标准化：未来的 RTOS 将广泛支持 ISO26262（道路车辆功能安全）功能安全标准，并针对不同级别的自动驾驶开发专门的安全认证机制，确保在高安全性环境中的可靠运行。（3）实时与非实时任务的协同管理l 增强的虚拟化技术：RTOS 将进一步发展虚拟化技术，实现实时任务与非实时任务的安全隔离，并优化资源利用率和系统性能。l 多核处理器优化：RTOS 将优化对多核处理器的支持，确保实时任务在多核环境中高效调度和执行，避免资源竞争和瓶颈。（4）多域融合与集中计算l 中央计算单元支持：RTOS 将优化以支持车辆中央计算单元（CCU），统一管理多个功201、能域（如驾驶辅助、信息娱乐、车身控制）。l 域控制器集成：随着多个功能域集成到少数几个高性能控制器中，RTOS 需要支持更复杂的任务调度和资源管理，确保各域之间的任务协同工作。（5）能效管理l 动态功耗管理：未来 RTOS 将更加注重动态功耗管理，通过智能调节系统频率和电压，平衡性能需求与能耗，延长电池续航时间。l 能源优化算法：RTOS 将集成复杂的能源优化算法，实时监控和调节车载系统能耗，确保在不同驾驶条件下的最佳能效表现。（6）实时性保障机制l 超低延迟通信：RTOS 将支持更低延迟的通信协议（如时间敏感网络 TSN），在高数据吞吐量情况下依然满足严格的实时性要求。l 确定性调度算法改进202、：RTOS 将在确定性调度算法上进一步优化，确保所有关键任务都在预定时间内执行，满足复杂车载系统需求。（7）系统可更新性与长期维护l 分区更新与无缝切换：RTOS 将支持分区式 OTA 更新，允许在不中断系统关键任务的情况下更新组件，减少更新对车辆使用的影响。l 长生命周期支持：RTOS 将优化架构，支持汽车全生命周期内的多次更新和维护需求，包括新功能添加和安全补丁的快速部署。中国汽车基础软件发展白皮书 5.0058（8）智能化与自适应能力l AI 驱动的资源调度：RTOS 将引入人工智能，通过历史数据和实时反馈动态调整任务调度和资源分配，优化系统性能。l 自适应安全机制：RTOS 可能集成自203、适应安全机制，根据系统运行状况和外部威胁自动调整安全策略，提高整体防御能力。车用 RTOS 的未来演进趋势将围绕高性能计算、功能安全、信息安全、能效优化和智能化展开，以适应自动驾驶和智能网联技术的发展需求，同时确保系统的安全性、可靠性和实时性。4 Safety LinuxLinux 操作系统由于：a)生态强大，支持多种程序语言与开发工具；b)支持多任务多用户调度；c)内部自带防火墙、入侵检测，能在多数情况下满足对网络安全性的需要；这几个特点，被多家车厂和零部件供应商选择应用到自动驾驶控制器中。但 Linux 本身在功能安全方面存在缺陷，因此业内普遍的做法是针对 Linux 操作系统做功能安全方204、面的设计和开发，增强后的 Linux一般被称为 SafetyLinux（功能安全 Linux 操作系统，以下简称 SafetyLinux）。SafetyLinux 内核在汽车功能安全相关领域的应用场景包含高级辅助驾驶（ADAS）、高级自动驾驶（AD）、舱驾一体、汽车中央计算平台等。在这些应用场景中 SafetyLinux 内核可以支撑运行最高 ASIL-B等级的应用程序。ADAS/AD 的部分应用功能为 ASIL-B 等级。SafetyLinux 内核可以支持 QM（QualityManagement，功能安全技术体系下的“风险边界”，控制到 QM 风险等级的危害即为“可容忍的”）和ASIL-205、B（汽车完全完整性等级 B 级，最高为 D 级）的中间件及应用程序同时在用户态运行，同时确保QM 和 ASIL-B 软件之间有充分的隔离，不会相互干扰。用于支持功能安全 Linux 内核开发的软件工具链也满足功能安全的要求，可以支持 ASIL-B 软件的开发。在自动驾驶系统的场景下，Linux 系统至少需要支撑 QM 和 ASIL-B 的应用软件运行。所以 Linux 内核自身也至少需要具备 ASIL-B 的功能安全等级。如图 4.1-9 功能安全 Linux 系统概念框图所示，内核中的所有子系统都应具备 ASIL-B 的功能安全等级。在实际的产品安全分析过程中，应对 Linux 内核的各个子206、系统进行进一步细分，识别出更多子模块。图4.1-9 功能安全Linux系统概念框图中国汽车基础软件发展白皮书 5.00594.1 技术特性（1）Safety Linux 技术要点在提升自动驾驶 Linux 系统功能安全特性方面，主要工作考虑以下方面：l 针对 Linux 基线选型，选择开源社区 LTS（LongTermSupport，长期支持）版本作为基线来源，可供参考的版本基线如 Redhat 的 CentOS、Debian、YoctoLinux 等，并根据目标芯片平台的BSP（BoardSupportPackage 板级支持包，以下简称 BSP）支持情况作选择。为使 Linux系统达到安全207、完整性等级 ASILB，除了 Linux 内核之外，Linux 内核相关的开发工具链和软件基础库都需要满足功能安全合规的要求。l 进行 Linux 系统危害分析和风险评估：确定 Linux 系统应用在自动驾驶软件中的支撑作用，从自动驾驶细分应用功能出发分析可能的危害以及这些危害发生的概率和严重程度，这是确立ASIL 等级的基础。进行故障模式、影响和诊断分析（FMEDA），通过 FMEDA 分析证明 Linux内核及其相关组件满足 ASILB 标准中的单点故障指标（SPFM）和潜在故障指标（LFM）。从产品功能需求到 Linux 内存分配过程中都需要优化任务调度、进程管理以及内存管理，并有效定义208、目标 ASIL等级、Failsafe、FTTI（Faulttoleranttimeinterval 故障容错时间间隔）等，采用高效的检查方法对需求进行验证，同时基于需求进行精炼并提取有效的数据流和控制流，进行分析验证。l 安全监控：使用外部监控组件或虚拟机监控程序来托管安全相关的操作，确保内核操作的安全性。例如，EBcorbosLinuxforSafetyApplications引入了基于虚拟机监控程序的安全扩展，符合ASILB/SIL2安全要求。l 硬件和软件的冗余设计：硬件层面，设计电源监控系统以确保 MCU（微控制单元）的电源供应在安全工作范围内，并在检测到电源故障时将 MCU 复位至安209、全状态。例如，使用宽 VIN 监控器进行 MCU 电源监控，并确保监控器与电源输出无关，以避免共因失效；使用功能安全型稳压器的集成 PGOOD 引脚作为监测欠压和过压故障的安全机制，并确保诊断覆盖率满足ASILB 要求。软件层面进行接口层抽象，在用户态抽象出接口层，接管 Linux 内核的某些操作，通过这个接口层实现功能安全逻辑。例如，使用 AUTOSAR 的 AP 版本或在 Linux 上运行虚拟机来实现功能安全逻辑。依据计算机系统中的 Amdahl 定律来计算容错系统的可靠性改进，确保所有组件采用冗余设计，使得单点故障不会导致整体系统失效。l 增加外部安全机制（比如程序流监控、数据流监控、210、冗余计算、冗余存储等）等方面的有效实施：通过高效的配置工具（如 OSADLMinimizationtool）针对需求分析的 Strace 信息对内核进行裁减，依据最佳时间或产品的特性对内核进行配置，最后基于检查加分析的方法对内核进行配置和验证。l 持续的缺陷管理和更新：保持 Linux 内核的更新，及时打补丁以修复缺陷，同时保持与原生态的兼容性，确保系统的安全性和可靠性。值得注意的是，Linux 系统按上述方式被改进和配置以确保满足在汽车安全关键型应用中的可靠性和安全性；然而部分安全改造在一定程度上可能导致改造后降低 Linux 的扩展性、灵活性。除了以上措施，也可采用将 Linux 整体当做211、软件组件来进行软件组件鉴定（ASILB）的方法，但是这类鉴定对超大型软件代码不一定适用，且相关的标准也还在制定过程中。中国汽车基础软件发展白皮书 5.0060（2）Safety Linux 挑战随着汽车逐渐从硬件定义向软件定义转变，开源软件和Linux系统在汽车应用中的重要性日益凸显。SafetyLinux作为开放架构操作系统的基础，为汽车制造商提供了一个灵活、可定制且安全的平台。它允许开发者在保证安全性的同时，快速开发和部署各种车载应用。这种开放性使得汽车制造商能够更好地应对快速变化的市场需求和技术创新。SafetyLinux在汽车行业中的典型使用场景主要包括ADAS（高级驾驶辅助系统）、仪212、表集群（InstrumentCluster）和V2X，对应这些场景分别有不同的技术需求。ADAS（高级驾驶辅助系统）l 提供符合 ISO26262（道路车辆功能安全）标准的安全运行环境l 确保实时性能，如快速响应紧急制动l 支持复杂的传感器融合和数据处理l 便于功能安全认证仪表（InstrumentCluster）l 保证关键信息（如速度、警告）的准确显示l 支持现代数字仪表盘的高性能图形需求l 实现与车辆其他系统的安全集成l 提供灵活的界面定制和更新能力V2X（车辆对外界通信）l 提供安全的通信机制，保护敏感数据l 支持低延迟的实时信息处理l 确保在复杂环境下的系统可靠性l 便于实现和更新国213、际通信标准l 与ADAS系统无缝集成综合而言，SafetyLinux 一般需要具备以下特性来满足相应汽车系统的需求，a)功能安全：SafetyLinux设计符合ISO26262 等汽车功能安全标准，达到 ASIL-B 的要求。b)实时性能：优化的实时内核确保快速响应和低延迟。c)可靠性：提供严格的内存保护和进程隔离机制。提供稳定的运行环境，减少系统崩溃和错误的可能性。d)开放可定制：基于 Linux 具有强大的生态系统和开发工具。允许汽车制造商根据特定需求定制和优化系统。e)安全通信机制：支持安全的数据传输和处理。f)硬件兼容性：支持广泛的车规级硬件平台。要实现以上技术特性并不容易，最主要的难214、点是功能安全特性，因为达到 ASIL-B 的要求，非常不容易，其主要存在的难点如下：l Linux 内核庞大的代码量和相对复杂的设计，全面分析和验证如此大规模的代码库是一个巨大的挑战。l Linux 生态系统，涉及众多贡献者和频繁的更新，这种复杂性使得追踪和验证每个代码更改的安全影响变得困难。l 功能安全认证（如 ISO26262 或 DO-178C）要求详细的文档和严格的开发流程，而 Linux 快中国汽车基础软件发展白皮书 5.0061速的开发周期和频繁的更新可能与功能安全认证所需的严格控制和验证过程不兼容。l Linux 作为一个通用操作系统，在设计之初没有基于功能安全，设计注重功能性和215、灵活性，且具有一定的非确定性，这与功能安全要求的可预测性和确定性行为相矛盾，如何实现 Linux 功能安全没有现成的方法。l 功能安全系统需要长期稳定的版本，而 Linux 社区倾向于快速迭代和频繁更新。如何在保持系统稳定性的同时，及时应用 Linux 重要的安全补丁和系统更新，确保每次更新或修补后系统仍然满足功能安全要求是一个持续的挑战。l 对 Linux 系统的安全性能进行量化分析和统计验证是一个复杂的过程，需要开发新的方法和工具。总之，SafetyLinux 在当前汽车行业中扮演着至关重要的角色，它为开放架构操作系统提供了一个安全、可靠的基础。其核心价值在于确保车辆关键系统的功能安全，同216、时保持 Linux 的开放性和灵活性。通过严格的安全机制、确定性行为、故障检测和隔离等技术，SafetyLinux 为 ADAS、车辆控制系统和 V2X等安全关键应用提供了可靠的运行环境。4.2 演化趋势（1）Linux 达成功能安全合规的趋势随着自动驾驶行业的高速发展，智能网联汽车的各类标准体系逐渐完善，整车厂出海需求增长，对采用 Linux 应用于自动驾驶的功能安全合规性要求逐渐趋严，Linux 系统为确保智能驾驶的安全可靠，需建立成熟且可量化分析、可执行的功能安全体系结合功能安全的分析和处理。Linux 作为宏内核解决方案（包括宏内核、C 库及 C 编译器等外部库）至少有 200 万行代217、码需要达成ISO26262 标准下的 ASIL-B 的功能安全等级合规，这对自动驾驶行业来说无疑是一个很大的挑战。目前难点主要在错误监控、分类和实时处理，以及如何保证在硬件失效和软件崩溃下汽车仍具有最低限度的安全性。在中国汽车工业协会 AUTOSEMO 工作组内有一批领先的企业投入 Linux 功能安全实践，如长安汽车的 Linux 内核态功能安全诊断模块将会在 2025 年获得功能安全认证；截至 2024 年 9 月零束科技的功能安全 LibC 库、C 编译器和 IPC 模块；地平线征程 5 的 BSP 获得 ASILB；赛福纳斯科技的功能安全SafenuxLinux 核心内核等。国际上的整218、车厂和相关 Linux 企业也在积极推进针对开源软件的功能安全国际标准的演进，随着 ISO8926 的发布，行业内对于开源软件有了新的实践路径，该标准在未来两年内的落地实践效果，一定程度上也会影响 ISO26262 第三版内容的制定。预计 Linux 系统解决方案的功能安全有望在 20262027 年得到解决。（2）功能安全 Linux 的生态合作底层操作系统的安全性、稳定性、可靠性是整车安全和性能的保障，需要行业共建，打造一个标准的、符合汽车应用需求的 Linux 版本。功能安全 Linux 内核涉及到内核数百万甚至上千万行代码的功能安全合规的目标，单凭一家或少数几家公司基本不可能在合理的成219、本（行业预估对 Linux 内核做 ASILB 认证成本为 100RMB/行）下达成这项目标。针对自动驾驶对功能安全的特殊要求，还需要对 Linux 系统持续进行功能安全特性开发，优化操作系统内核的中断、内存、调度处理流程，将影响功能安全的操作系统内核异常事件以可靠的方式通知业务软件，帮助实现系统整体功能安全。为实现自动驾驶中功能安全 Linux 系统，需要各家整车厂、代表企业及生态合作伙伴共同努力，将基中国汽车基础软件发展白皮书 5.0062于 Linux 的自动驾驶系统分解成多个部分从而逐个击破功能安全合规的问题。例如：a)芯片厂商提供内核中功能安全合规的芯片驱动代码。因为自动驾驶芯片驱动220、软件与芯片硬件是强耦合的，所以只有芯片厂商可以基于功能安全芯片硬件开发安全合规的芯片驱动代码。芯片厂商可以提供 QM 版 Linux 芯片驱动代码来支持客户的早期开发和 POC(ProofofConcept)项目，同时提供 ASIL 合规版 Linux 芯片驱动及 STL（Safetytestlibrary）安全测试库来支持客户的量产项目。b)Linux 系统类厂商提供功能安全合规的内核基本功能软件模块和 Linux 系统开发工具链；也可以牵头将多家厂商分别提供的 Linux 功能安全软件模块、工具集成成为一套完整的功能安全 Linux 系统解决方案，多家厂商可以共享功能安全 Linux 系统221、解决方案所带来的价值。此外建议 Linux 系统类厂商研究汽车行业对底层软件的应用和需求特点，提供适合于当前的商业模式。c)自动驾驶软件厂商提供各类功能安全合规的自动驾驶中间件软件模块和应用软件模块。自动驾驶软件厂商也可以将部分重要的 Linux 用户态开源软件模块转化成功能安全合规的模块，集成到自身的中间件应用软件产品中。自动驾驶中间件和应用软件可以基于 Linux 系统优化并达到最佳的运行效率，从而节约硬件资源。d)功能安全认证机构通过深度参与 Linux 功能安全社区以及 Linux 认证活动，为功能安全 Linux 软件生态中的多家厂商提供标准化、高效率的功能安全培训和认证服务。通过标222、准化、规模化的培训和服务，功能安全认证机构可以加快认证周期以适应功能安全 Linux 自动驾驶软件的快速迭代的产品特征，同时降低客户的安全认证的成本，提升自动驾驶功能安全领域整体工程效率。e)整车厂提出自动驾驶系统及 Linux 系统功能安全的需求，并支持其供应链中的 Linux 系统生态伙伴。如整车厂在自动驾驶功能安全 Linux 的开发过程中，发起 POC 项目，使得生态伙伴能够深入理解产品及业务的功能安全需求，在产品化项目中快速交付可量产的功能安全 Linux 系统解决方案。f)标准化组织、生态联盟提出对自动驾驶 Linux 系统的功能安全要求和团体标准，更新方法论，统一行业认知，弥补现223、有国际功能安全标准的不足，提高基于功能安全 Linux 的自动驾驶系统整体安全性、性能和性价比。例如针对本报告中分析现有功能安全标准，以及行业最佳安全实践的不足，建议后续通过行业标准/团体标准的形式，给出软件和操作系统功能安全的实施细则和行业最佳实践，形成对现有功能安全标准的补充。g)在政策层面，建议对自动驾驶领域的企业在 Linux 系统的功能安全合规及认证领域的技术成果进行支持。展望未来，SafetyLinux 将继续演进以应对新的挑战。这包括适应不断更新的安全标准、整合 AI 安全机制、支持混合关键系统，以及融合功能安全和信息安全。随着汽车行业向软件定义汽车转变，SafetyLinux 224、的重要性将进一步凸显。汽车制造商和技术供应商需要密切关注 SafetyLinux 的发展，并积极参与其生态系统建设。只有这样，才能在保证安全性的同时，充分利用开源技术的创新潜力，在竞争激烈的汽车行业中保持领先地位。SafetyLinux 不仅是一个操作系统，更是汽车行业安全创新的重要推动力。（二）开放架构下的操作系统安全开放架构虽然带来了更高的灵活性和可扩展性，但同时也增加了系统的攻击面和安全风险。因此，操作系统必须采用多层次的安全架构，涵盖信息安全、功能安全、网络安全等多个维度，以保护系统免受潜在威胁。中国汽车基础软件发展白皮书 5.00631.信息安全开放架构的操作系统具有代码透明、可定制225、性强等优点，但也面临着独特的安全挑战。这些挑战主要包括：a.代码公开带来的潜在漏洞暴露；b.第三方软件和驱动的安全风险；c.系统配置的复杂性增加了误操作的可能性；d.网络连接的普遍性增加了远程攻击的风险。1.1 一般安全技术为应对这些挑战，现代操作系统安全策略通常采用多层次、纵深防御的方法，结合技术手段和管理措施来保护系统的完整性、机密性和可用性。在开放架构的操作系统中，信息安全主要关注以下几个方面：l 机密性（Confidentiality）：确保信息只能被授权用户访问。l 完整性（Integrity）：保证信息在存储和传输过程中不被未经授权的修改。l 可用性（Availability）：确226、保授权用户能够及时访问所需的信息和资源。为了实现上述安全目标，开放架构的操作系统通常采用以下典型安全策略：（1）访问控制策略l 自主访问控制（DAC）：允许资源所有者自行决定访问权限。l 强制访问控制（MAC）：系统根据预定义的安全策略控制访问。l 基于角色的访问控制（RBAC）：根据用户在组织中的角色分配权限。l 基于属性的访问控制（ABAC）：根据主体、客体、操作和环境的属性动态决定访问权限。（2）身份认证和授权l 多因素认证：结合密码、生物特征、硬件令牌等多种方式。l 单点登录（SSO）：用户只需登录一次即可访问多个相关系统。l 最小权限原则：仅授予用户完成任务所需的最小权限。（3）加密227、和数据保护l 文件系统加密：保护静态数据的安全。l 网络通信加密：如 SSL/TLS 协议，保护数据传输安全。l 内存保护：防止缓冲区溢出等攻击。（4）审计和日志l 系统日志：记录重要系统事件和用户活动。l 安全审计：定期分析日志，检测异常行为。（5）漏洞管理l 定期更新和补丁管理：及时修复已知漏洞。l 漏洞扫描：主动识别系统中的安全漏洞。（6）隔离和沙箱技术l 虚拟化技术：隔离不同的应用环境。l 容器技术：提供轻量级的应用隔离。l 应用沙箱：限制应用程序的系统访问权限。中国汽车基础软件发展白皮书 5.00641.2 可信计算可信操作系统（TEEOS）是一种具有高度安全性和可靠性的操作系统，它228、通过硬件和软件的结合，提供更强大的安全保障。可信操作系统的主要特征包括：（1）可信根（RootofTrust）建立从硬件到软件的信任链，通常包括：l 可信平台模块（TPM）：提供硬件级的安全功能。l 安全启动：确保系统启动过程中每个组件的完整性。（2）完整性度量和验证l 在系统启动和运行时对关键组件进行完整性度量。l 使用可信存储保护完整性度量基准值。（3）强化的访问控制l 实现细粒度的访问控制策略。l 支持多级安全（MLS）模型。（4）安全域隔离l 利用硬件虚拟化技术实现强隔离。l 实现可信执行环境（TEE），如 ARMTrustZone。（5）动态安全策略l 支持基于上下文的动态安全策略调229、整。l 实现自适应安全机制。（6）安全审计和取证l 提供不可篡改的审计日志。l 支持实时安全事件分析和响应。1.3 演化趋势操作系统的信息安全一直在发展，目前的几种发展趋势为：（1）零信任安全模型零信任安全模型是一种新兴的安全架构，它的核心理念是”永不信任，始终验证”。在开放架构的操作系统中，零信任模型的实施包括：a.持续身份验证：不仅在登录时，而是在整个会话期间持续验证用户身份。b.最小权限访问：精细化控制每次资源访问。c.微分段：将网络分割成小的安全区域，限制横向移动。d.持续监控和分析：实时监控所有网络流量和系统活动。（2）人工智能和机器学习在安全中的应用a.异常检测：使用 AI 算法识230、别异常的系统行为和用户活动。b.自动化威胁响应：根据 AI 分析结果自动采取防御措施。c.预测性安全：预测潜在的安全威胁并提前采取防护措施。（3）容器和微服务安全随着容器和微服务架构的普及，操作系统安全也需要适应这种新的部署模式：a.容器隔离：加强容器间的隔离，防止容器逃逸。中国汽车基础软件发展白皮书 5.0065b.镜像安全：确保容器镜像的完整性和安全性。c.运行时保护：监控和保护容器运行时的安全。（4）边缘计算安全随着边缘计算的发展，操作系统安全需要扩展到分布式环境：a.轻量级安全解决方案：适应资源受限的边缘设备。b.分布式信任机制：在边缘节点间建立信任关系。c.安全数据同步：确保边缘和云231、端数据的安全同步。在开放架构下，实施全面的信息安全策略，结合可信计算技术，现代操作系统正在向更安全、更可靠的方向发展。然而，安全是一个持续的过程，需要不断适应新的威胁和技术变革。随着人工智能和边缘计算的发展，操作系统安全将继续演进，为数字世界提供更坚实的保护。2.功能安全功能安全（FunctionalSafety）是指确保系统或产品在其预期的生命周期内，即使在某些组件发生故障的情况下，仍然能够安全运行，从而避免对人员造成伤害或对财产造成损害的能力。功能安全在操作系统领域的应用主要分三个方面：对 Linux 内核做功能安全补强，在本章节第一部分第 4 小节 SafetyLinux有详细介绍；通过232、功能安全认证的实时操作系统；操作系统作为重要组成，使系统满足功能安全需求。本小节主要介绍用于操作系统领域的常见的安全措施。2.1 安全冗余功能安全通过风险评估工具（如 HAZOP、FTA）识别潜在的危害，并评估其风险水平。基于风险评估的结果，制定明确的安全要求规范，定义系统应具备的安全功能。通过设计满足安全要求的系统架构，并考虑冗余、故障检测等机制，并确保通过测试和验证确保系统满足安全要求。在功能安全领域，通常会采用冗余设计来提高系统的可靠性和安全性，尤其是在那些对安全性有极高要求的应用中，比如航空航天、汽车、铁路交通和工业自动化等。冗余可以采取多种形式，包括软件冗余、时间冗余、路径冗余和硬件233、冗余等。几种典型配置:2oo2(TwooutofTwo):2oo2配置意味着有两个相同或相似的组件，并且需要两个组件中的至少一个正常工作以保持系统的运行。在这种配置下，如果其中一个组件发生故障，则另一个组件可以接管其功能，从而维持系统的安全性。2oo3(TwooutofThree):2oo3配置则包含三个相同的组件，但只需要其中任意两个组件正常工作即可保证系统的运行。与 2oo2 相比，2oo3提供了更高的容错能力，因为即使有一个组件发生故障，系统仍然可以通过其他两个正常工作的组件来维持运行。这两种配置通常应用于表决系统中，其中各个组件输出的结果会被比较，以决定最终的系统行为。表决逻辑可以帮助234、过滤掉错误的输出，从而提高系统的安全性和可靠性。这两种配置的实现通常需要从硬件、操作系统、到软件的逐一认证及整合，构造完整的认证系统。2.2 异构设计异构系统是指由不同类型的组件构成的系统。这些组件可能基于不同的架构、使用不同的编程语言或者有不同的设计原理。异构系统的设计目的是通过多样化来降低共模故障的风险，即不同类型的错误不会同时影响所有的组件，从而提高了整个系统的安全性和可靠性。异构系统的不同的计算平台可能会并行执行同一任务的不同版本，这样即使有一个版本出现了缺陷，其他版本仍可以提供正确的结果。异构系统对系统的组成部分，包括硬件、操作系统、应用软件提出了更高的质量要求，在通用的软硬件模块基235、中国汽车基础软件发展白皮书 5.0066础上，通过冗余来实现降低故障概率的目标。这些方案都是为了增强系统的安全性而设计的，每种方案都有其适用的场景。选择哪种方案取决于具体应用的需求、成本考虑以及所需的故障容忍级别。在实际部署时，还需要综合考虑系统的复杂性、维护性以及长期支持等因素。在车用操作系统中，功能安全是关键领域，将面向更高的实时性、更强的隔离性、更智能的检测与预防、以及更严格的安全认证方向发展。（三）人工智能与操作系统基于 AI 自我学习与不断进化的能力，在操作系统领域，AI 与操作系统的结合主要有三个方面:分别是 AIforOS,即基于 AI 在研发领域、软件工程的能力，促进操作系统技236、术演化；二是 OSforAI，即操作系统用于支撑 AI 的训练和进化；第三是 AIasOS，即形成 AIOS，由 AI 执行操作系统的任务调度和资源管理，AI 本身成为操作系统。1.AI for OS基于 AI 训练的操作系统的开发模型，可以用于对操作系统进行设计、编码、调测、优化、漏洞分析、补丁检测和安全增强方便的促进。AI 在研发和软件工程领域的介绍请参考本书 5.3 节。2.OS for AIAI 大模型的训练，对计算资源有极高的需求。（1）虚拟化对 AI 的支持为了提高资源利用效率和系统灵活性，虚拟化技术在面向 AI 大模型的开放式软件架构中发挥了至关重要的作用。虚拟化对于 AI 的支237、撑，包括 AISoC 的虚拟化支持，AI 加速器（如 NPU、GPU 等）的虚拟化适配，跨域数据传输，AI 加速器相关固件加载，资源管理等。虚拟化技术为 AI 应用的部署提供了坚实的基础。通过隔离性，虚拟化技术确保 AI 应用不会与关键的控制应用产生相互影响，从而保障系统的安全性与稳定性。同时，虚拟化的灵活性和可移植性为 AI 应用提供了更加便捷的部署方式。在面向 AI 的虚拟化部署场景中，以下几种应用尤为重要：a)AI 训练：为不同的训练任务提供独立环境，避免资源冲突，确保训练过程的稳定性。b)模型测试与验证：通过快速创建多种测试环境，加速 AI 模型的测试与验证，提高开发效率。c)AI 部238、署：l 分布式计算：灵活部署实时和非实时环境，支持多层级端边云分布式计算，以应对大规模计算需求。l 资源动态扩展：在 AI 模型训练或推理的过程中，动态扩展资源以应对峰值需求。为进一步优化 AI 的部署环境，虚拟化技术需要在以下几个方面进行改进：a)提高性能，降低损耗：针对 AI 应用的部署需求，优化虚拟化技术，确保虚拟化环境下的计算性能接近物理环境。b)确保实时性：在 AI 应用中增强交互和数据处理能力的同时，虚拟化技术必须确保系统能够满足实时响应的需求，特别是在工业和汽车领域。c)强化安全性：加强虚拟化环境的安全防护机制，确保功能安全和信息安全，为 AI 应用的数据安全和关键设施的功能安全239、提供保障。中国汽车基础软件发展白皮书 5.0067d)提升兼容性与互操作性：确保虚拟化技术的良好兼容性，为 AI 应用的软件和硬件需求提供稳定的部署环境，并增强系统的互操作性。（2）实时操作系统对 AI 的支持实时操作系统（RTOS）不仅需要满足传统实时系统的要求，如实时性和可靠性，还需要适应 AI 模型的复杂性和资源密集型特点。实时操作系统主要应用在关键的边缘终端设备上，在部署端为 AI 应用提供数以亿计的实时边缘终端，无论是做为数据来源或做为实时处理的端节点，在 AI 应用交互架构中，发挥了末端神经以及“本能反应”的作用。实时操作系统（RTOS）是端边云中不可或缺的重要节点，且数量庞大。在240、边缘设备的实时操作系统，有着通用操作系统的作用，也有其独特的特性。RTOS 负责高效地管理设备的计算资源（如 CPU、GPU）、内存和存储空间，确保 AI 应用推理过程、或者在线训练，如强化学习过程能够获得所需的资源。实时操作系统确保在有限资源的情况下，通过高效的调度机制，确保实时任务能够及时执行，同时支持非实时的 AI 任务。实时操作系统支持故障检测与恢复机制，确保系统的高可用性和稳定性，并通过支持功能安全以及信息安全的安全机制，保护数据和模型不被恶意攻击，并确保数据隐私。通过优化节点间的通信，减少延迟并提高数据传输效率，特别是对于分布式部署的场景。实时操作系统在支持 AI 大模型的应用时需241、要提供 AI 应用所需的必备环境。如高性能计算支持，支持并行计算框架（如 TensorFlow、PyTorch）。通过低延迟实现实时响应及控制，通过优化内核、减少上下文切换等手段，减少任务执行及对中断的响应延迟。支持 AI 应用所需的多样化的硬件加速器，如 CPU、GPU、NPU、BPU、FPGA、ASIC 等硬件加速器，提高计算效率。提供内存优化，针对大模型的内存需求，优化内存管理策略，减少碎片化。同时还需保持实时操作系统的自有特性，提供功能安全及信息安全增强，确保数据传输和存储的安全性，防止未授权访问。通过增强可扩展性，支持模块化设计，支持 AI 应用快速迭代的，易于添加新功能或更新现有功242、能。实时操作系统需要随着 AI 应用架构的发展，不断地改进和革新。随着边缘计算的普及，RTOS 将更加关注如何在边缘设备上高效地运行 AI 模型，减轻云中心的负担。RTOS 将更紧密地与专用硬件加速器集成，以支持更高性能的计算任务。RTOS 将不断发展关注其功能安全机制以及信息安全机制的实现，以应对日益增长的安全威胁。RTOS 将朝着更加智能化的方向发展，能够根据环境变化自适应调整其行为，以提供实时与非实时任务的混合执行能力提高系统资源利用率。随着开源文化的推广，RTOS 也需要更加开放，鼓励社区贡献和创新，形成更强大的生态系统。RTOS 以其高可靠性和实时性著称，在自动驾驶和智能座舱等需要精243、准时序控制的场景中至关重要。AIOS 在设计时，需要将 RTOS 的优势融入其中，以确保系统在处理 AI 任务时仍能满足严格的实时性要求。l 实时任务调度：AIOS 需要集成 RTOS 的实时任务调度机制，确保 AI 大模型的推理和计算任务能够在规定的时间内完成，避免因延迟而导致的安全风险。l 实时数据处理：RTOS 可以为 AIOS 提供高效的数据处理能力，使得传感器数据能够及时送达AI 模型进行处理，进而提升自动驾驶系统的响应速度和决策准确性。通过将 RTOS 与 AIOS 结合，系统能够在确保实时性和可靠性的前提下，支持复杂 AI 计算任务的高效执行。l 任务优先级管理：在 AIOS 中244、，可以借鉴 RTOS 的任务优先级管理策略，将关键 AI 任务设置为高优先级，确保这些任务在资源紧张时仍能得到优先处理。l 多任务并行执行：AIOS 应支持多任务并行执行，通过 RTOS 的调度机制，优化 AI 大模型的中国汽车基础软件发展白皮书 5.0068计算任务和系统其他任务之间的协调，实现资源的最优配置。（3）Safety Linux 对 AI 的支持SafetyLinux 作为一类针对安全关键系统设计的操作系统，能够为 AI 提供强大的安全保障。l 功能安全性：SafetyLinux 通过严格的安全认证和安全机制，确保操作系统在执行 AI 任务时不会因系统故障导致功能失效。基于 Sa245、fetyLinux 的安全架构，可以构建出一个高度可靠的 AI计算环境。l 信息安全防护：SafetyLinux 的安全特性可以用于保护 AI 模型和数据，防止外部攻击或内部恶意行为对系统造成影响。SafetyLinux 中的多层安全机制可以帮助 AI 系统实现功能和信息安全，从而提升整个系统的可靠性。l 隔离与容错机制：基于 SafetyLinux 的隔离与容错机制，通过虚拟化技术实现系统内部不同任务和模块的隔离，防止单点故障对整个系统的影响，并通过容错机制提升系统的整体安全性。3.AI as OS近些年，国内外有多家研究机构进行能自我调度任务、分配资源的 AIOS 研究。其中，LLMOS（246、大模型操作系统）有较大进展。LLMOS 不仅适用于智能手机、智能家居等消费电子领域，还在自动驾驶、工业自动化等需要高度智能化和实时响应的场景中展现出强大的潜力。它代表了未来操作系统的发展方向，即从传统的功能性操作系统向智能化、自我优化的方向演进。大模型操作系统（LLMOS）是指基于大语言模型（LLM）技术构建的操作系统，旨在通过深度学习和自然语言处理等 AI 技术，为操作系统提供智能化能力。图4.3-1 大模型操作系统如图 4.3-1大模型操作系统所示，AgentApplications 与 LLMKernel 和 OSKernel 的交互流程具有明确的层次分工和交互机制，如下描述：l Age247、ntApplications：位于系统的最上层，直接与用户交互，提供特定的功能或服务。例如，中国汽车基础软件发展白皮书 5.0069旅行规划、编程辅助、数学计算等。这些应用程序是用户体验的直接接口，负责收集用户输入并显示处理结果。l LLM 系统调用接口：这是 AgentApplications 与 LLMKernel 交互的桥梁。当 AgentAppli-cations 需要利用大型语言模型（LLM）的能力进行推理或生成内容时，它们通过此接口发起请求。该接口负责将应用程序的高层请求转化为 LLMKernel 可以理解和处理的操作指令。l LLMKernel：负责处理与 LLM 相关的所有任务248、。LLMKernel 接收从 LLMSystemCallIn-terface 传递的请求，执行必要的语言模型推理或数据处理，然后返回结果。这个模块可能还包括管理和优化 LLM 性能的工具，如缓存、模型切换等，以确保高效的处理速度和资源利用。l OSKernel：作为系统的核心模块，OSKernel 管理整个系统的资源，如 CPU 调度、内存管理、文件系统访问、网络通信等。AgentApplications 在需要系统级服务时（例如文件读写、进程管理、网络请求等），会通过系统调用与 OSKernel 进行交互。OSKernel 确保这些请求得到适当的资源分配，并维护系统的稳定性和安全性。交互流程249、：l AgentApplications 发出请求：当用户在应用程序中执行操作（如输入查询或命令）时，AgentApplications 会决定是否需要 LLM 的处理能力或操作系统资源。l LLM 请求：如果需要 LLM 支持，应用程序通过 LLM 系统调用接口向 LLMKernel 发送请求。LLMKernel 处理请求，例如生成自然语言响应、分析文本或执行数据推理。l 操作系统服务请求：如果应用程序需要访问系统资源（如存储文件、分配内存），它会通过标准的系统调用接口向 OSKernel 发送请求。OSKernel 负责提供这些服务，并确保资源的有效利用和安全管理。l 结果返回：处理完成后250、，LLMKernel 和 OSKernel 将结果返回给 AgentApplications，后者再将最终的处理结果呈现给用户。数据流和控制流：l 数据流：用户输入的数据首先流向AgentApplications，经由LLMKernel或OSKernel处理后，生成的结果再流回 AgentApplications，最终反馈给用户。l 控制流：AgentApplications 通过调用接口控制 LLMKernel 和 OSKernel 的行为。它们根据任务的需要，发出不同的系统调用，触发相应的内核服务或 LLM 处理。操作系统内核根据这些调用执行具体的资源管理、任务调度等操作。这种架构设计使得251、 AgentApplications 能够高效地利用 LLM 的强大功能，并访问操作系统提供的广泛资源和服务，最终实现丰富、动态且高响应的用户体验。通过明确的模块分工和接口定义，系统确保了应用程序层与内核层之间的高效、可靠、互动。LLMOS 基于自我进化能力能够使操作系统在运行过程中持续优化自身性能、提高安全性、增强稳定性，并且自动适应新的硬件和 AI 模型。LLMOS 的自我进化能力可以通过以下几种机制实现：l 在线学习与更新：基于在线学习机制，实时分析和学习操作系统在运行过程中的数据和行为模式，根据学习结果动态调整资源分配策略、优化任务调度机制，并适应新加入的 AI 模型和硬件设备。l 自252、适应算法：通过自适应算法，根据系统的运行状况和外部环境变化自动调整系统参数。例如，中国汽车基础软件发展白皮书 5.0070系统可以根据当前的计算负载、温度、能耗等因素，动态调整 AI 模型的推理频率、调度策略以及资源分配，以实现性能和能效的平衡。l 自治安全管理：利用 AI 技术自动监控和检测潜在的安全威胁，并在检测到异常时自动采取应对措施。例如，系统可以自适应地增强安全防护机制、隔离潜在危险模块或动态修复漏洞，从而提升整体系统的安全性。l 智能故障恢复：在发生系统故障时，通过智能故障诊断和恢复机制，自动分析故障原因，并采取相应的修复措施，减少系统宕机时间，提升系统的可用性。中国汽车基础软件发253、展白皮书 5.0071五、开放式软件架构的工具链随着开放式软件架构的不断演进，传统的开发方法和工具已难以满足其快速变化的需求。为了有效应对这一挑战，我们需要对开发方法和工具进行全面的升级和优化，以确保技术的前瞻性和市场的适应性。与传统的汽车软件开发相比，新的汽车软件开发过程中需要引入敏捷开发模式、模块化设计、标准化接口、持续集成与持续部署、跨领域合作、安全管理、AI 赋能等新的开发理念，通过不断优化开发方法和工具，持续推动汽车软件行业的持续高品质发展。本章节将介绍开放式软件架构的工具链，旨在提出一套定义清晰、合理、简单、统一的开发方法和开发者工具，促进开放式软件架构的标准化使用。（一）经典工具254、链在汽车领域开放式软件架构中，开发者工具是连接软件开发者与系统硬件、中间件及最终应用的桥梁，也是保障系统有效开发和维护的关键。随着汽车电子电气架构的不断复杂化，特别是在多域融合架构中，各种开发者工具的应用显得尤为重要。这些工具不仅需要支持不同领域的开发需求，还需要提供统一的接口和标准，以确保系统各部分的顺畅集成。它们不仅提升了开发效率，还确保了软件质量，促进了多域融合架构下软件的快速迭代与部署。在智能网联汽车领域，高效、全面的开发工具链是支撑技术创新与产品快速迭代的关键，也是影响开发效率、软件质量、调试和测试工作的重要因素，因此简单易用的开发者工具是极其重要的。1.面向 MCU 的标准基础软件255、的开发者工具针对传统 MCU 领域，ClassicPlatformAUTOSAR 的开发方法学分为三个阶段：系统设计与配置阶段、ECU 设计与配置阶段、代码生成阶段。Arxml 作为系统描述文件，用于对软件组件、ECU 资源和系统约束机型描述。如图 5.1-1 所示，为 ClassicPlarformAUTOSAR规范定义的开发流程。图5.1-1 CP AUTOSAR定义的开发流程中国汽车基础软件发展白皮书 5.0072a.第一阶段：定义系统配置文件，包括硬件的功能组件、系统通信方式、通信节点、报文数据类型等，通过这些配置约束生成系统描述 arxml 文件和通信描述 arxml 文件。系统描述256、 arxm 定义系统组件接口、组件内部行为、组件接口数据类型、组件间连接关系等。通信描述 arxml 定义整个系统通信种类，包括总线报文、总线信号、组件和信号的映射关系等。b.第二阶段：提取各个 ECU 相关的系统描述文件，对 ECU 完成必要的配置，例如 OS 调度、各个BSW 模块的配置、组件和底层服务的 Mapping、MCAL 配置等，并生成对应模块的 arxml 描述文件。c.第三阶段：通过工具将模块 arxml 描述文件和 SWC 描述文件生成逻辑代码，经由编译器和连接器生成可执行文件。上述 AUTOSARClassic 方法论描述了从系统设计到各个 ECU 配置到代码集成的整个过257、程，建立了一套标准化的平台方案，大部分工作都可以通过工具配置完成，缩短了产品的开发及设计周期，提升了平台产品的复用性。2.面向 SOC 的标准基础软件的开发者工具针对自适应应用的开发，AdaptivePlatformAUTOSAR 将应用程序的开发方法论进行了标准化，在应用服务设计的同时引入了 Manifest 的概念，它是 AUTOSAR 的一种模型描述文件，主要包含自适应应用程序部署所涉及的一些配置信息，可用于基于工具化配置的应用开发。如图 5.1-2 所示，为 AdaptivePlatformAUTOSAR 规范所定义的开发方法。图 5.1-2 AP AUTOSAR定义的开发方法面向SO258、C的标准基础软件的开发者工具，遵循 AdaptivePlatformAUTOSAR 标准的开发方法学，其配置流程包括：（1）软件层设计a.服务接口设计：定义服务的接口类型，如 Method、Event 及 Field，并完成对应接口的数据类型的定义；b.服务接口部署：选择服务所使用的通信协议，将服务接口与应用层协议进行绑定。c.服务接口序列化：提供为 SOME/IPpayload 序列化方式的配置功能，可配置通信数据的序列化/中国汽车基础软件发展白皮书 5.0073反序列化（通信接口级别）规则。d.应用服务设计：定义软件功能组件、定义可执行文件、定义可执行程序，设计三者关联配置关系。（2）硬件259、层设计a.以太网拓扑设计：在域控制器中支持多网卡网络拓扑设计，通过配置实现服务与网卡的绑定；b.Machine 设计及部署：设计 ECU 级别的全局文件存储限制、功能组、诊断车辆宣告标识、诊断逻辑地址、PNC 网络、网络拓扑等；（3）通信层设计a.软/硬件映射：通过将 Machine 与服务接口、服务实例、进程进行 Mapping，在软硬件解耦的前提下实现映射，部署后可进行通信；b.服务实例化：为服务接口分配实例 ID，应用通过服务实例进行通信，一个服务接口可以实例化为多个实例；c.以太网通信设计：实现服务发现多播 IP 地址绑定、定义服务发现端口号、定义 TCP 通信心跳包时间间隔、定义接收260、 TCPACK 时间间隔等。3.车辆基础服务的开发者工具针对跨域跨核的整车业务需求，车辆基础服务中间件基于跨域服务进行整车视图下的跨域跨核开发。车辆基础服务为应用层提供各类可复用的服务模块，使应用开发者可以直接调用封装好的各类通用服务，减少服务的重复代码维护，提高开发效率。图5.1-3 车辆基础服务开发流程车辆基础服务中间件工具链作为车辆基础服务配置工具，实现了基于 AUTOSARCP/AP 组件的配置功能和框架，扩展了整车视图下的跨域跨核应用配置方法学，如图 5.1-3 车辆基础服务中间件开发流程所示，主要包括如下方面：（1）设计a.业务设计：根据业务设计功能；b.配置监控：根据私有协议的 261、ID 分配原则为业务分配 ID；c.工具配置：根据业务 ID 分别配置 SOC 和 MCU 的功能服务。（2）开发与部署a.模块应用开发：根据设计的私有协议 ID 开发业务功能；b.编译与集成：分别对 SOC 和 MCU 的工程使用对应编译链进行编译；（3）测试与验证：运行系统，对程序功能验证。具体流程如图 5.1-4 所示：中国汽车基础软件发展白皮书 5.0074图5.1-4 开发流程4.整车通信总线的开发者工具针对跨域跨核应用的通讯，整车通信总线进行整车视角的通讯矩阵配置。整车通信总线为应用层提供整车通讯基础框架，使应用可以直接调用封装好的统一的通讯接口，无需关注具体通讯的细节，便于应用的262、快速开发以及跨域跨核的移植。如图 5.1-5 整车通信总线的开发方法所示，具体步骤如下：a.MCU 在整车通信过程中，首先要配置 PortInterface，并导入到 MCUSWC 中。PortInterface 用来映射成整车通信总线的数据结构。一个 PortInterface 下的 Signal 可以映射一个数据结构，也可以多个PortInterface 下的 Signal 映射一个数据结构。一个数据结构与一个 Topic 对应，表示这个 Topic 对应的数据类型。配置完成后，生成 MCU 用的 S2S 通信配置的 arxml 和对应的 S2S 代码；b.SOC 在整车通信过程中，也需要263、配置通信数据结构，同样是与 Topic 对应，也可以通过 Protobuf导入自定义的数据结构进行对应。除此之外，整车通信总线已经内置了预定义消息，定义了常用的数据结构，可以直接使用；c.配置好 Topic 和对应的数据结构，就可以做通信的映射，指定整车通信总线针对一个 Topic 的接收端和发送端，接收或发送端指向 MCU 的就会用到从 PortInterface 下 Signal 映射的数据结构。接收或发送端是 SOC 的可以使用整车设计中 arxml 中定义的，导入的 Protobuf 数据类型和预定义数据类型。AP 的 CM 模块也可以通过整车通信总线的 Broker 映射与整车通信总264、线互相通信。完成映射配置后，会产生整车通信总线的配置文件。可以进行 MCU 的应用开发，也支持用 Python 开发应用。中国汽车基础软件发展白皮书 5.0075图5.1-5 整车通信总线的开发方法（二）开放的高效开发框架业界需要一种低门槛的、高效率的、AI 友好的开发语言和编程框架，以便于高质量的开发创新应用，满足汽车行业快速增长的软件创新需求。一个开放的高级语言开发框架是可以满足这些需求，它具有如下特征：l 提高开发效率：开放的高级语言开发框架提供丰富的预定义组件和模块，使得开发者能够快速构建应用程序；l 简化复杂度：这些框架通常遵循成熟的设计模式和最佳实践，帮助开发者用简单的方式去管理复265、杂的系统交互，如多线程处理、网络通信、数据管理等；l 促进代码复用：通过提供标准化的接口和可重用的代码库，减少重复工作，并且有助于保持代码的一致性和可维护性；l 增强可扩展性：框架的设计需要考虑系统的扩展需求，允许开发者轻松地添加新功能或修改现有功能，而不破坏原有的系统结构；l 改善软件质量：由于框架通常经过广泛的社区测试和验证，因此它们可以帮助减少开发过程中的错误和漏洞，提高软件的整体质量和安全性；l 支持跨平台开发：高级语言框架应该支持跨平台开发，这意味着开发者可以使用相同的代码库为目标于不同操作系统或硬件环境的应用程序进行开发；l 降低技术门槛：统一的开发框架应该具有较低的学习门槛，使新266、成员更容易融入项目，并快速掌握开发技巧；l 降低维护成本：由于代码更加标准化和模块化，因此长期来看，这会减少维护成本并简化未来的升级过程。中国汽车基础软件发展白皮书 5.0076开放的高效开发框架可以提前产品上市时间，提升软件质量，同时降低总体软件成本。随着智能化的发展，车端会与云端、移动终端有更多的交互。同时车内的 IVI 与其他控制器的交互也越来越多。云、移动终端、IVI 的 Android 都属于互联网生态，在互联网生态中，WebService 是多设备间的调用最常用的方式。整车软件架构中增加定义 WebService 的支持，可以更好的支持与互联网生态的协同。同时针对车内的应用，提供车267、内统一的通信框架与对外的 WebService 间的映射，使得基于整车通信总线开发的应用，既可以实现车内的 SOA，又可以与互联网无缝连接，同时也可以更便捷的支持 AI 交互。1.高效开发框架的定义目前汽车软件领域主流的编程语言是 C/C+，相比 C/C+来说，高级编程语言具有学习成本低、程序可维护性强、移植性强等特点。但同时高级语言也有一些缺点，在执行效率、资源占用、安全性上不如C/C+。因此一般比较复杂的软件系统，在开发平台中需要同时支持 C/C+等低级语言用于满足执行效率与资源占用要求，同时也需要支持高级语言用于创新、开放、开发效率的要求。随着电子电气架构的演进，域控制器芯片的算力显著提268、升，也为高级语言的应用提供了合适的运行环境。为加快汽车软件的开发、迭代进程，需要一种易学的、开发效率高的高级语言来支撑软件开发。这里我们以 Python 语言为例，对高效开发框架进行说明。Python 的开发社区活跃性较高、对全面的标准库与第三方库支持度高，同时也是一门 AI 友好的语言，可以方便的将各种各样的 AI 开源算法库和基础工具整合起来。例如 Python 支持现代 AI 框架，包括 TensorFlow、PyTorch 等主流深度学习框架都提供了良好的 PythonAPI 支持，这使得在汽车领域进行复杂的感知任务（如物体识别、路径规划等）变得更加简单直接；同时 Python 语言具269、有丰富的 AI 基础库支持，如 NumPy、Pandas、Matplotlib、Scikit-Learn 等，这些库可以极大地简化数据处理、机器学习模型训练等工作，加速 AI 开发流程。因此 Python语言受到 AI 开发者、算法开发者的青睐，用于解决大量逻辑复杂、规模庞大的工程应用问题。因此，引入 Python 高效开发框架作为 AI 基础支撑，是符合汽车软件领域的未来发展趋势的，但是仅仅将 python 的运行环境和 AI 库、框架移植到车端无法完成车辆 AI 的整体开发支持，需要考虑如何将车端原有基础功能如 AP 中的诊断、通信、日志等与 Python 开发的 AI 应用很好的融合起来270、。基于 Python实现的高效开发框架可以解决此问题。综上原因，如图 5.2-1高级语言开发框架所示，框架应具备包装 AUTOSARAP 和通用服务的能力，如提供 AP 及中间件的 Python 接口，达成 Python 开发的组件与 C+开发组件互通，同时基于高效开发框架开发的 Python 应用可以复用 AUTOSARAP 的安全机制和服务，从而降低开发成本。图5.2-1 高级语言开发框架中国汽车基础软件发展白皮书 5.0077另外，目前车内以太网使用的常用通信协议为 SOME/IP 与 DDS，这些协议在车内运行的 AUTOSARAdaptive、AUTOSARClassic、POSIX271、 系统的节点可以很容易的进行使用和支持。但在座舱域通用的 An-droid 系统中，由于 Java 原生不支持 SOME/IP 与 DDS 协议，因此需要作转换并带来额外开销，也增加了应用与系统的耦合度。同时，在与云、手机通信中，由于车内与云及手机端不同的通信协议，也会涉及协议转换。上述问题都会带来开发效率和耦合性问题。WebService 是一种跨编程语言和跨操作系统平台的远程调用技术，在 IT 与互联网领域使用广泛，生态成熟且丰富。云端、互联网、手机端，都是充分使用 WebService 作为远程调用的方法。而汽车软件目前使用 WebService 作为远程调用方法的比较少，是因为并未所有272、节点都具备支持 WebSerivce 的 HTTPServer 及 Web 框架，以及 C/C+不足以有效支撑 Web 框架的开发效率优势。因此，在 Python 开发框架之上封装一套 WebService 开发框架，借此提供更通用、更便捷、更直接可见的交互手段，这就使得高效开发框架具备了 Web 访问消息的能力，并提供 SOVD(Service-OrientedVehicleDiagnostics)、OpenAPI 的支持，同时允许用户开发自己的服务程序，从而进一步提高交互的便捷性，降低开发成本，极大的提升云端和座舱域开发者的开发效率。2.高效开发框架的功能高效开发框架的结构介绍如下：a)应273、用层：用户可以开发 PythonAdaptiveApplication（PAA）或 PythonScript（PS）；也可以通过 HTTP 请求访问提供的 WebService；还可以通过 Framework 提供的 API 工具进行 API 测试。b)WebServiceFramework：框架核心部分，也是资产复用的核心，提供 Web 屏蔽、参数转换、调度、异常处理、调试和日志、以及认证、权限、会话、账户管理、预定义消息、日志等级控制、SOVD、OpenAPI功能；ServiceFramework 可以运行在 Web 进程中作为 WebService 的入口屏蔽 django 等 Web 274、基础框架的依赖，也可以通过 CLI 运行 PyService 或执行针对 PyService 开发的测试用例。主要包含以下子功能模块：i.预定义消息：作用是在软件中抽象车辆基本数据(例如车速数据、雷达数据等)，然后发布到整车通信总线,统一车辆数据获取接口。其他应用程序或服务可从整车通信总线中订阅预定义消息。ii.日志控制：允许远程调整日志记录的级别，能够通过Web服务在一个中心位置管理多辆车辆的日志设置，便于集中管理，并且可实时查看和调整日志等级，有助于故障诊断和性能优化。iii.SOVD 支持：AUTOSAR 新的诊断标准，Service-OrientedVehicleDiagnostics275、（面向服务的车辆诊断），通过采用面向服务的方法来改进传统的车辆诊断过程。在传统的诊断过程中，诊断请求和响应通常是硬编码的，每个诊断服务都有其固定的请求和响应格式。然而，在现代汽车中，随着电子系统的复杂性增加，这种硬编码的方式变得难以管理和维护。因此需要引入 SOVD，其核心理念是将诊断服务视为一组独立的服务，这些服务可以通过定义好的接口来访问，有助于简化车辆诊断的开发和维护，同时也为未来汽车电子系统的扩展提供了更大的灵活性。这种方法提供了以下优势：l 灵活性：SOVD允许动态配置和更新诊断服务，不需要更改底层的硬件或软件。l 可扩展性：新的诊断服务可以很容易地添加到现有的系统中，而不会影响到现276、有的服务。l 标准化：SOVD提供了一种标准化的方式来定义和实现诊断服务，使得不同制造商之间的互操作性成为可能。l 简化集成：通过将诊断服务抽象为服务，SOVD使得不同ECU之间的集成变得更加简单。iv.OpenAPI支持：为了更好的支持外部系统远程访问车内的AI功能，需要通过API实现数据的交换，中国汽车基础软件发展白皮书 5.0078并灵活地集成到各种外部系统中；而OpenAPI规范可以确保API的标准化定义，便于开发者无歧义的理解和使用 API 进行开发和集成。c)PythonFramework：框架核心部分，主要是对下层 AUTOSARAdaptivePlatform 和 ASF 中间277、件的 Python 封装。d)广义操作系统层：是使用 C+开发的 ServiceFramework 和 AUTOSARAP 和 ASF 中间件。3.高效开发框架的接口参考Python 应用开发是建立在 AUTOSARAP 和 ASF 中间件之上的，本框架封装它们的功能，对上层应用提供 Python 语言形式的接口，其主要接口见下表：表5.2-1 Pyhton开发框架接口关联模块接口描述整车通信总线Node应 用 使 用 Node，可 以 创 建 出Topic的 Reader/Writer，这些对象隶属于这个 Node，同时 Node需要使用Executor 执行器，把其中所有通信相关的对象运行278、起来。ReaderTopic 的订阅方，通过 Node 来创建 Reader 的实例。WriterWriter 是一个 Topic 的发布方，通过 Node 来创建 Writer 的实例。Timer基于消息总线的定时器，通过Node 来创建其实例。ServerServer 是一个 Method 的提供方，通过 Node 来创建 Server 的实例。ClientClient 是一个 method 的使用方，通过 Node 来创建 Client 的实例。整车数据处理框架VStatusTableVStatusTable 为 车 辆 状 态 表 操作类。EMExecutionClientExecut279、ionClient 类用于向 EM 报告进程状态。PHMSupervisedEntitySupervisedEntity 类用于向 PHM报告检查点。HealthChannelHealthChannel 类用于向 PHM 报告健康状态。LOGCreateLogger创建 Logger 对象。LoggerLogger 类 为 对 AP 的 Lt 的 py-thon 化的日志类。PERKeyValueStorage键值存储操作类。FileStorage文件存储操作类。ReadWriteAccessor文件存储中读写文件操作类。ReadAccessor文件存储中读取文件操作类。中国汽车基础软件发展白280、皮书 5.0079关联模块接口描述DiagAbstractGenericExcute重写读取、写入 did 的操作类，抽象类，需要继承实现 Read、Write、CancelRead、Cancel-Write 方法。GenericDataIdentifier读取、写入 did 的代理类，使用22/2e 服务时，先继承重写 Ab-stractDataElementExcute 类，然后构造 GenericDidProxy 类。Monitor诊断监视器类，提供 Offer 功能阻塞进程。Condition故障产生的前置条件类，当事件绑定的所有前置条件都达到要求时，才会处理通过 monitor 上报281、的事件，否则忽略。OperationCycle操作周期类，故障管理功能工作的循环周期。DiagUdsNrcErrc调用 Offer 或 ReportMonitorAc-tion 时可能发生的内部错误的类型。DataElement外部扩展数据读取类，可选服务，提供 Offer、StopOffer 函数。WebService 开发框架接口以 URL 方式定义，接口示例：http:/192.168.182.129:8080/e/system/Admin.getAdmin.json?name=”abc”表5.2-2 WebService开发框架接口说明URLPart说明http:/192.168.18282、2.129:8080协议、IP 和端口部分，以实际部署情况为准/e/固定，表示 wsgi 前缀system/Admin.getAdmin表示 system 包下执行 Admin 类的 getAdmin 方法。.json表示使用 json 格式输出，后续可扩展 XML 等格式?name=abcname 为方法参数名，“abc”为参数值的 Json 格式4.高效开发框架的开发方法Python 开发框架的开发方法与 AUTOSARAdaptivePlatform 的应用开发方法一致。WebService 是基于 Python 框架提供 Web 服务的，因此 WebService 开发框架的使用时，需283、要配置Python 框架。高效开发框架的具体开发流程如图 5.2-2高效开发框架的开发方法所示：中国汽车基础软件发展白皮书 5.0080图5.2-2 高效开发框架的开发方法在使用高效开发框架进行应用开发时，如下配置需要特别关注：a.Python 框架层功能的配置：i.错误码定义的配置；ii.WebService 日志的配置；iii.API 使用权限定义，配置预置角色是否允许操作 API。b.锁：如果存在并发访问的情况下，可能需要考虑锁机制，本框架应该提供完善的锁机制。（三）AI 大模型赋能创新工具链AI 大模型在汽车软件开发中扮演着重要的角色，为智能汽车发展提供坚实的技术基础。本节将从 AI辅284、助软件工程的角度探讨相关的应用。汽车软件开发流程包括软件需求开发、软件架构设计、软件代码开发、软件测试测试等，工程师可借助以 AI 大模型为基础的软件工具辅助开发和测试，如 ChatGPT、智谱 AI、通义千问、GithubCopilot、Codex 等。1.软件工程变革AI 大模型促进汽车软件开发工程，由面向过程的开发模式变为面向目标的软件开发模式。传统软件工程是以人为本的协同式开发，强调开发流程、工具、人之间的协同配合，而以 AI 大模型为底座的软件开发过程，是以数据为本的生成式开发，对协同的要求没有那么高，通过减少不必要的协同，能极大的提高开发效率。1.1 面向过程的开发模式如图 5.3285、-1ASPICE 软件开发模型所示，目前汽车软件开发主流遵循 ASPICE 软件开发模型，AS-PICE 包括了 32 个过程域，其中核心有 16 个过程域。ASPICE 本身是一种面向过程的开发模型，涉及到多个工序和过程，多个开发工种进行协同，通过需求跟踪来保证需求到交付的完整性。中国汽车基础软件发展白皮书 5.0081图5.3-1 ASPICE软件开发模型1.2 面向目标的开发模式利用 AI 将现有的 ASPICE 部分过程进行整合，并对接相应的业务子系统，由工程师给出系统和软件需求，由 AI 执行并生成 ASPICE 过程输出的相应设计文档、代码、测试报告等，工程师对目标交付物进行确认。286、通过减少过程节点和协作，来优化软件开发的质量、周期、成本。传统的软件工程，需求在传递的过程中总有丢失，上下游工序在保证需求准确性时，需要大量的标准化 UML 设计和面对面沟通讲解，产生了很大的沟通协作成本，而效果又不尽人意。同时大量的文档需要人工写作，同时极易产生设计与实现不符的问题。如图 5.3-2 所示，AI 大模型赋能软件工程，使开发过程全数字化，通过 AIGC 生成软件开发过程中的各种产物：如设计文档、代码、测试脚本、测试报告等。过程中对人的依赖性极大的降低，交付周期极致缩短，真正实现持续交付。图5.3-2 AI用于软件工程中国汽车基础软件发展白皮书 5.0082软件工程大模型还可以进287、行模块化定制部署，包括：(1)软件需求完善：需求收集、需求分析、文档补全、需求验证、沟通桥梁；(2)软件架构设计：性能优化、复杂设计、快速迭代、架构评估、文档生成；(3)软件代码开发：代码补全、代码解释、代码优化；(4)软件测试：测试计划编制、自动生成测试、测试用例优化；以下进行详细阐述。2.软件需求开发在软件需求开发中，工程师可利用 AI 大模型构建软件需求开发 AI 助手，通过编制软件需求开发场景下的提示词，使 AI 大模型快速理解软件需求开发流程，在人工梳理和拆分整车系统功能后，AI 大模型可自动生成软件需求文档，极大地提升软件需求的开发效率，同时减少人工编写软件需求规格书的错误和遗漏。288、主要包含：1.需求理解与生成；2.文档编写；3.需求要点总结；4.内容问答；5.任务总结。2.1 标准解读在汽车软件开发过程中，工程师需遵循大量的行业标准，如 AUTOSAR 标准、汽车电子系统功能安全国际标准（ISO26262）、汽车数据处理安全技术要求（GB/T41871）等，工程师在开发前需花费大量的时间完成标准解读。利用 AI 大模型的文本理解能力，工程师将标准文档输入给 AI 大模型进行解读，生成标准解读报告，总结提炼重点内容，提升标准解读的效率。如图 5.3-3 标准解读所示，在标准解读方面有很多用法，常用的有提炼标准要点，介绍标准的背景，发布信息，针对标准的某个部分进行提问等。常289、用模型：通义千问，文心一言，ChatGPT 等。图5.3-3 标准解读中国汽车基础软件发展白皮书 5.00833.软件架构开发传统的系统架构和软件架构，是精心设计的构成式软件架构，受限于架构设计师的经验和能力，设计质量大为不同。新的架构设计师可能会带来不同的架构方案，缺乏继承性。老的架构设计师可能继承以往架构，同时也继承大量的技术债，缺乏创新性。AI 大模型赋能软件架构设计，是一种生成式软件架构，相比传统的软件架构，我们不必从顶层到底层逐步分解，层层定义算法、逻辑、数据、输入输出详细接口、交互流程、状态机等。我们只需要给出系统和软件需求，较为抽象的目标定义，AI 就能帮完成接下来的架构、设计、290、编码、测试等工作，并且保持开然的设计与实现的一致性，需求到交付的一致性。通过模型训练和新创新数据训练，AI 能自动给到我们最优软件架构，自带继承性和创新性。软件架构设计由构成式软件架构，向更高效和高质量的生成式软件架构方向演进。如图 5.3-4 所示为传统的软件架构方法：图5.3-4 传统的软件架构方法如图 5.3-5 所示为 AI 生成式软件架构方法：图5.3-5 AI生成式软件架构方法中国汽车基础软件发展白皮书 5.00843.1 基础软件配置AUTOSAR（AUTomotiveOpenSystemARchitecture）是一个为汽车电子控制单元（ECU）提供标准化软件架构的全球开发合作291、组织，旨在提高汽车软件的可移植性、可扩展性和可维护性，主要包括两种主要平台：经典平台（ClassicPlatform,CP）和自适应平台（AdaptivePlatform,AP）。以 AUTOSARCP 为例，传统的软件开发流程如下：1)定义系统配置文件，包括硬件、软件组件、系统约束条件。2)根据系统配置文件，生成 ECU 配置描述文件。3)使用配置工具生成 ECU 基础软件（BSW）。4)定义数据类型及接口，包括基本数据类型、应用数据类型、发送者-接收者接口等。5)DBC 文件导入。6)设计软件组件，建立软件内部行为。7)生成 RTE 和 BSW 配置代码，并完成集成。8)对生成的代码进行验292、证和测试。传统的 AUTOSARCP 软件开发流程冗长复杂，软件故障排查困难，软件质量严重依赖工程师的能力和经验，软件开发的门槛较高。基于 AI 大模型强大的语义理解和代码生成能力，软件开发人员创建 AUTOSARCP 软件配置的智能AI 工具，结合开源 AI 部署框架 LangChain，通过文本向量化的方式将 AUTOSARCP 的标准转换为 AI 大模型能够理解的向量数据，使 AI 大模型快速掌握 AUTOSARCP 相关的行业标准，精通 AUTOSARCP软件开发流程。相比之下，由 AI 大模型辅助进行的 AUTOSARCP 软件开发流程可由先前的八个步骤简化成如下四步：1)使用 AU293、TOSAR 配置工具创建空白工程文件。2)在 AI 工具中配置工程路径、DBC 路径及 AUTOSAR 配置工具路径。3)通过和 AI 工具进行对话，引导 AI 大模型完成 ECU 配置、BSW 代码生成、RTE 代码生成等人工配置流程。4)对生成的代码进行验证和测试。在 AI 大模型的辅助下，AUTOSAR 软件工程服务能够快速度配置生成解析文件和框架代码，软件开发工程师能将数月的开发周期缩短至数天，极大地提升软件开发效率和质量，同时提高工程师的软件开发能力，降低软件开发门槛。4.软件代码开发在汽车软件领域，AI 大模型凭借着其强大的自然语言理解和代码生成能力，使更多的主机厂在软件开发流程中294、引入 AI 大模型。相对于人工软件开发，AI 大模型辅助下的软件开发能自动化完成大量重复性开发任务，并对软件潜在漏洞进行修复，缩短开发周期，极大提升软件开发效率和质量。在软件代码开发中，工程师可使用 GithubCopilot、Codex 等代码工具辅助开发。以 GithubCopilot代码生成工具为例，其使用流程如图 5.3-6基于 AI 的软件代码开发流程所示，能够帮助工程师完成代码编写、自动补全、代码优化、代码注释、单元测试等工作，提高软件开发效率。此外，工程师可使用 AI 大模型生成软件代码开发场景下的 AI 助手，通过自然语言交互的方式自动生成数据库、CAN 通讯等标准化模块代码，295、大大降低了软件开发门槛，有效提升工程师的代码编写能力。中国汽车基础软件发展白皮书 5.0085图5.3-6 基于AI的软件代码开发流程常用用法有：a.提出需求，让模型生成代码b.粘贴代码，提出任务描述，在这个代码基础上进行修改c.粘贴代码，让模型给出代码质量分析如图 5.3-7基于文心一言的 C+代码编写示例应用举例：用 c+写一个单例模式的程序图5.3-7 基于文心一言的C+代码编写示例中国汽车基础软件发展白皮书 5.00864.1 BSP 生成BSP（板级支持包）是嵌入式系统开发中重要组成部分，它通过提供硬件抽象接口、设备驱动程序和启动代码，使操作系统能够在硬件平台上正常运行。传统的 BS296、P 的生成过程复杂，涉及硬件分析、启动代码开发、驱动程序编写、操作系统移植和系统调试等多个环节，为 BSP 生成带来了极大的挑战，且开发人员需要针对不同的硬件平台进行适配开发，最终开发完成的代码质量依赖工程师的软件开发经验，难以适应软件的快速迭代。基于 AI 大模型的代码解析和处理能力，可实现自动识别硬件平台特性、自动生成设备驱动软件及代码漏洞的自动诊断和修复。此外，AI 大模型能够根据工程师的需求，自动选取合适的软件工具完成 BSP代码生成，并基于自身海量的代码仓库，可向工程师提供大量的开发建议，拓宽工程师的开发思路，更加高效、可靠地完成 BSP 代码生成。如图 5.3-8BSP 编写示例所297、示，在 linuxBsp 生成方面，常用的用法有根据描述生成设备树，对设备树中的某些字段，节点提问，在已有的设备树代码上，根据要求修改代码等。图5.3-8 BSP编写示例中国汽车基础软件发展白皮书 5.00875.软件测试在DevOps理念的推动下，持续集成与持续测试的紧密结合将更加深入。测试不再是开发过程的最后一环，而是贯穿整个软件生命周期。在软件测试中，工程师可使用 AI 大模型生成软件测试场景下的 AI助手，通过输入软件测试场景下的提示词，上传测试用例编写模板，AI 大模型可辅助完成测试脚本、测试用例的开发，保证脚本代码和测试用例的规范性、一致性，提升测试脚本和测试用例的开发效率及质量。298、在完成软件测试后，AI 大模型可辅助工程师分析定位软件测试问题，提供问题解决方案，修复软件漏洞，提高软件问题解决效率，确保软件产品的稳定性和可靠性。中国汽车基础软件发展白皮书 5.0088六、开放式软件架构的生态建设开放式软件架构的生态系统包含技术生态和产业生态。技术生态主要包括接口统一、技术路线共识，这样有利于产业链上下游合理分工，化整为零，协作开发。产业生态，则是建立开源开放、多层解耦的生态体系，有利于软件架构的演进和技术路线的聚焦发展，促进产业协同进步。本章节将主要介绍技术生态和产业生态的构建工作。（一）技术生态1.开放式接口的统一API 接口的作用是将软件系统抽象出来，简化了不同应用程299、序之间的交互过程。API 接口的使用，使得软件开发变得更加快速、高效，并增强了软件的可扩展性和可维护性。当前各大主机厂以 SOA 的形态研究为目标，提出分层解耦开发目标。从底层的内核与基础中间件，到框架支撑层的功能软件，再到上层应用软件，明确了各层之间的向下依赖关系，各层之间通过规范化的API进行交互，实现了不同层次间的分离与解耦。汽车软件 API 的统一化和标准化对于智能汽车发展至关重要。API 标准的制定和遵循是为了确保 API 在不同的开发场景中能够正常运作，并且具备一致的行为和接口。当多个开发者或多个团队同时开发不同的模块或服务时，API 标准可以提供一种共同的编码约定和规范，使得各个300、模块或服务之间能够无缝地协作和集成。在 API 标准发展过程中，过去行业中出现的 API 标准已经初步规定代码的命名规范、命名约定和语法规则。通过统一的命名和语法规范，提高代码的可读性和可维护性。API 规范标准化的三大关键要素如下：（1）完整性；即 API 规范必须包含 API 的所有必要信息，包括 API 的接口、协议和安全措施等。（2）准确性；即 API 规范必须准确地描述 API 的功能和行为，不得包含任何错误或歧义。（3）简洁性；即 API 规范必须简洁明了，易于理解和使用，不得包含任何冗余或不必要的信息。API 规范标准化工作需要建立开放、透明和包容的参与机制，鼓励来自不同行业、领301、域和职能的利益相关者共同参与 API 规范标准化工作。定义清晰的参与规则和程序，确保行业参与者有平等的机会参与标准化过程，使其意见和观点得到充分的考虑和尊重。定期组织研讨会、论坛等活动，促进技术生态参与者之间的交流，共同探讨和解决 API 规范标准化过程中的问题和挑战。1.1 POSIX 随着汽车行业迅速发展产生了从传统机械和硬件为中心的工程到以软件为中心的开发的转变。在这一转变中，两个关键因素显现出来：遵循可移植操作系统接口（POSIX）标准的兼容性，以及集成开源第三方库。POSIX 标准，即可移植操作系统接口（PortableOperatingSystemInterface），定义了一组操302、作系统接口，旨在跨多个类似 Unix 系统保持兼容性。POSIX 兼容性确保了为一个 POSIX 兼容系统编写的软件可以轻松移植到另一个系统上，减少了软件移植的兼容性问题。对于汽车行业而言，这一标准变得越来越重要，原因包括：中国汽车基础软件发展白皮书 5.0089（1）安全关键应用中的实时操作系统（RTOS）汽车系统，如 ADAS、动力总成控制和制动系统，要求实时操作以确保安全性和性能。实时操作系统（RTOS）在这些应用中起着至关重要的作用，许多 RTOS 解决方案都是 POSIX 兼容的。POSIX 兼容性确保了开发人员可以利用标准化的系统调用，使得在不同平台上开发和维护实时应用变得更加容易303、。例如，制动系统可能需要在事件发生后几微秒内执行命令。POSIX 兼容的 RTOS 确保了软件能够在各种硬件平台上始终如一地处理这些关键时间任务。此外，这种标准化有助于简化安全关键系统的认证过程，例如符合 ISO26262 标准，该标准管理汽车系统的功能安全性。（2）高级驾驶辅助系统（ADAS）和自动驾驶ADAS 和自动驾驶系统依赖于复杂的算法，这些算法必须实时处理大量数据。这些系统通常涉及组件，如传感器融合、机器学习和计算机视觉，这些组件需要复杂的软件架构。POSIX 兼容性可以通过提供一组一致的 API（如内存管理、线程和进程间通信的系统级操作）来简化这些架构的开发。通过遵循 POSIX 304、标准，开发人员可以构建模块化系统，其中不同组件（例如感知、决策和执行）可以独立开发，但仍然能够无缝协同工作。此外，POSIX 兼容系统还可以简化各种第三方软件组件的集成，使得更容易将外部供应商或开源社区的创新纳入系统中。（3）车载信息娱乐系统（IVI）车载信息娱乐系统（IVI）是另一个 POSIX 兼容性发挥重要作用的领域。IVI 系统管理娱乐、导航和连接功能，它们必须与各种硬件组件（如显示屏、触摸屏和网络接口）交互。POSIX 兼容性使得 IVI 软件更容易跨不同硬件平台移植，从而降低了开发时间和成本。此外，POSIX 兼容的 IVI 系统可以利用广泛的开源软件，如多媒体框架和网络协议栈。通305、过确保与标准 Unix 类操作系统的兼容性，POSIX 兼容的 IVI 系统可以更轻松地集成第三方应用程序和服务，从而提供更丰富的用户体验。（4）电动汽车（EV）管理系统电动汽车（EV）管理系统，包括电池管理系统（BMS）和充电控制，要求可靠的软件在各种条件下运行。POSIX 兼容的操作系统通常用于这些应用中，以确保软件能够在从嵌入式控制器到中央处理器的不同硬件平台上高效运行。例如，BMS 必须监控和控制车辆电池的充放电，在性能与安全之间取得平衡。通过使用 POSIX 兼容的软件，开发人员可以利用标准化工具和库来完成实时数据处理、与外部传感器通信以及错误处理等任务。1.2 AUTOSARAUT306、OSAR（AutomotiveOpenSystemArchitecture）是一个开放且标准化的汽车电子软件架构，其目标是通过标准化接口和模块化设计，提高汽车软件开发的效率、质量和可维护性。其成立的本身目标在于标准化接口，具备如下特点：（1）提高互操作性：通过定义标准接口，使得不同供应商提供的软件组件能够无缝集成。（2）简化集成与测试：减少系统集成和测试过程中的兼容性问题，降低开发复杂度。（3）促进模块重用：使不同项目之间能够共享和复用既有的软件模块，节约资源。AUTOSAR 部分的内容在本书第三章有详细介绍，本小节略过。2.通信协议的统一在互联网领域中 SOA（面向服务的架构）已经被应用和实307、践了一段时间，但在汽车行业中，依然是相对较新的概念。在 AdaptivePlatformAUTOSAR 框架中，通信管理模块包括进程间通信和网络协议栈。中国汽车基础软件发展白皮书 5.0090鉴于整车应用场景和通信需求的特点，SOME/IP、DDS、AMQP、REST、MQTT、和 CoAP 等协议已被广泛应用，并且每种协议都至少有 10 种不同的代码实现。汽车通信协议的主要目的是实现车辆各部分之间的协同工作，提高安全性、可靠性和效率。汽车软件通信协议的统一对于汽车行业的发展至关重要，主要基于以下原因：标准化和兼容性：统一的通信协议能够确保汽车不同组件、系统之间以及车辆和外部网络之间的数据交换308、更加高效、稳定和安全。通过统一标准的约定，汽车通信协议可以提高汽车各个部件之间的协同工作的能力，从而提高安全性、可靠性和效率。技术进步和创新的推动：汽车通信协议的选择需要根据具体的应用场景和要求来进行，统一的通信协议有助于技术的进步和创新。SOA 架构主要目标是在域内服务和跨域服务打通车云的通信链路，但是目前 SOA 接口并没有完全统一的标准，没有统一标准就无法达成行业内的可通用性，行业需要一个技术生态共同解决通用性的问题。AUTOSEMO 已于 2021 年初步研讨汽车 SOA 架构设计与软件平台框架团体标准，该团标形成了系统的 SOA 架构，逐步推进各软件架构层的汽车通信协议统一。3.开发309、标准和流程的统一开放式软件架构的生态建设需要以标准引领为目标，统一加强标准体系建设及规范标准的开发流程。有利于：确保安全性和可靠性：统一的开发标准与流程有助于确保软件的质量和性能，减少安全问题带来的风险。提高开发效率：避免因标准不统一导致的开发混乱和重复性的工作。应对技术挑战：汽车软件开发面临着技术复杂性高、迭代快、安全要求高等挑战。开发标准与流程的统一，有助于工程师更好地聚焦这些挑战，应对技术问题。综上所述，开放的软件架构需要一个统一的开发标准与流程，以确保软件的质量、安全、效率并推动技术的持续创新和进步。4.开源库在汽车开发中的重要性使用开源第三方库已成为汽车软件开发中的一个重要考虑因素。310、开源软件（OSS）提供了许多优势，包括成本节约、获取前沿技术，以及利用全球开发者社区的能力。然而，将开源库集成到汽车系统中也带来了挑战，尤其是在确保符合行业标准和安全要求方面。（1）传感器数据处理现代车辆配备了一系列传感器，包括摄像头、LiDAR、雷达和超声波传感器。处理这些传感器的数据需要复杂的算法，如对象检测、跟踪和分类。这些算法中的许多作为开源库提供，例如用于 3D 数据处理的点云库（PCL）或用于计算机视觉的 OpenCV。通过使用开源库，汽车开发者可以加速传感器处理流水线的开发，并利用最新的研究成果。然而，将这些库集成到安全关键系统中需要仔细的验证和测试，以确保它们符合汽车行业的严格311、可靠性和性能要求。（2）自动驾驶系统中的机器学习和 AI机器学习（ML）和人工智能（AI）在自动驾驶系统中起着至关重要的作用，使车辆能够从数据中学习并在复杂环境中做出决策。像 TensorFlow、PyTorch 和 scikit-learn 等开源机器学习框架已成为开发汽车领域 AI 模型的热门工具。中国汽车基础软件发展白皮书 5.0091尽管这些框架提供了强大的功能，但在汽车应用中使用它们时需要解决一些挑战，包括确保模型的可解释性、可验证性和安全性。此外，开发人员还必须确保这些框架与底层 POSIX 兼容操作系统的集成不会引入性能瓶颈或安全风险。（3）网络与连接性随着车辆的日益互联，网络和312、通信协议已成为汽车系统的重要组成部分。开源网络库和协议（如用于消息队列和通信的 MQTT 协议或用于安全通信的 OpenSSL 库）常常用于联网车辆应用中。例如，车辆到一切（V2X）通信使车辆能够与其他车辆、基础设施和其他道路使用者进行通信。开源网络协议栈可以促进 V2X 解决方案的快速开发，但开发人员必须确保这些库的安全性、可靠性，并符合ISO/SAE21434 等汽车标准，该标准针对道路车辆的网络安全性。（4）IVI 和用户界面开发在 IVI（车载信息娱乐系统）领域，开源库在构建用户界面（UI）和多媒体功能中起着重要作用。像Qt 和嵌入式 Chromium 框架（CEF）这样的框架常用于开313、发现代化、响应迅速的 UI，这些 UI 提供了高质量的用户体验。这些库允许快速原型设计和开发，使汽车制造商能够跟上消费者对高级信息娱乐功能的需求。然而，将这些开源库集成到 IVI 系统中需要仔细考虑性能、兼容性和安全性。例如，在 IVI 系统中使用开源 Web 浏览器引入了潜在的安全漏洞，必须通过严格的测试和更新来缓解这些漏洞。（二）产业生态1.当前的问题与挑战在中国汽车基础软件发展白皮书 4.0 中，我们提到存在的问题有以下四个。l 国产基础软件装车量有待提高l 硬件、应用、开发者生态构建有差距l 部分标准追随国外，不能满足中国应用场景l 国产基础软件造血能力低过去一段时间的发展，部分问题已314、经有了一定的改善，比如目前国产基础软件装车率已从四年前的8%到现在占据了近三成以上。智能化标准这一块，也有 AUTOSEMO 提出的 ASF、车云一体等标准规范。但在产业链生态建设和国产软件造血能力上，一直没有大的突破。这反映在当下主要有三个方面的问题：低水平重复建设：当下中国汽车圈的热点词汇一定是“卷”。主机厂卷价格、卷配置、卷上市时间，这种氛围已经波及到整个产业链的上下游。在汽车产业新四化发展进入到智能化阶段，我们看到不仅有传统的主机厂、供应商在积极进行智能化转型，新势力基本沿着全栈自研的路线在做相关领域研发，科技公司和很多外部力量也纷纷下场。一时间市场红海一片，低水平重复建设比比皆是。这315、不仅导致行业整体议价水平低下，无法形成持续投入持续创新的研发与商业闭环，更是挤占技术创新所需要的人才、资金、设备等多方资源，严重影响行业的良性循环发展。软件价值不被认可：传统观念中汽车行业长期以来重视硬件的价值，对软件的重要性认识不足。定价机制即如何合理地为软件定价是一个挑战，特别是在软件成为汽车差异化的重要因素之后。软件的价值往往体现在用户体验上，但如果用户对此不够敏感，则可能不会愿意为此付费。这导致软件虽然是资金密集型投资领域，但无法让市场直接买单，进而影响后续的技术研发与创新。AI 大模型的训练重复投入大量资源：AI 大模型的训练依赖算法、算料、算力和场景，缺一不可。目前中国汽车基础软件316、发展白皮书 5.0092国内市场上，几乎每家都在针对 AI 大模型做相关投入。一方面同质化严重，算力相关的硬件设备价格昂贵且购买渠道受限，另外一方面针对大模型训练需要的算料和场景，以一家厂商去支撑覆盖不足。2.破局之道的思考针对上述问题，我们给出的解决方案是构建开源、开放、分层解耦的立体生态体系：建立评估和遴选体系：建立评估和遴选体系，避免业内扎堆重复投入单一领域，造成行业低水平内卷。行业标准的持续建设与推广：针对共性、平台性部分，建立统一标准和接口。营造出标准统一，各家针对实现做竞争的市场局面。行业联盟或其他合作形式：推动形成行业联盟或其他组织，进行资源整合和优化配置，避免资源挤占，影响技术317、创新。分层解耦，垂直分工：术业有专攻，聚焦每一领域的技术点，单点突破，提升整体研发效率和技术水平。坚持科学发展观：汽车产业作为最复杂最综合的载体，如何发展，路在何方，需要尊重客观发展规律，有耐心，持续投入。希望通过开放的平台，能够聚势、聚力，汇聚全行业力量，引导行业融合技术路线、推进标准共建，建立起破除内卷、协作发展、分层解耦的立体生态体系。中国汽车基础软件发展白皮书 5.0093七、AI大模型对整车软件发展趋势和技术路线的影响AI 大模型以其卓越的计算能力、深度学习能力以及广泛的应用场景，正在重新定义整车软件的架构和功能，加速整个行业向更智能、更高效和个性化方向迈进。本章节将探讨 AI 大模318、型对整车软件发展趋势和技术路线的诸多方面影响，探索 AI 大模型的更多可能。（一）发展趋势1.算法、算料、算力与场景AI 大模型的训练和升级，算法、算料（数据）、算力和场景缺一不可。在探索 AI 大模型对整车软件发展趋势和技术路线影响之前，先考虑 AI 大模型本身的发展对资源的需求：算法模型对计算、存储需求增加：大模型可以作为模块化端到端中的一个模块发挥作用。大模型也可以与模块化端到端算法配合，例如理想与清华共同提出的“快慢系统”架构（如图 7.1-1 所示），或者小鹏汽车的XNet+XPlanner+Xbrain架构。在车端侧部署的模型通常经过轻量化处理，但基于功能性、准确性、安全性的考量，319、模型参数规模仍然达到几十亿以上。对于端到端驾驶任务，为了避免累积误差和信息丢失，模型模块之间或者模型之间以多维特征空间中的多维数组或矩阵传递。这一种数据量更大且连续的数据形式，对数据的存储和传输效率（如零拷贝方式）要求很高。虽然感知、规控等算法业务内部传输的数据形式几经优化，但域之间、智能体之间、智能体内插件或工具库之间仍不乏人为数据的发布订阅，所需内存达到十几 GB，甚至几十 GB。如果采用多智能体的架构，对系统资源分配会有更高要求。图7.1-1 理想与清华提出的“快慢系统”架构芯片和工具链设计需支持算法快速迭代：当前的端到端算法和大模型大多基于 Transformer（一种广泛应用于自然语320、言处理中的深度学习模型）架构，相比过去卷积网络中以 4D 为主的比较小的张量，大模型结构中张量的维度更加多变，维度操作更加复杂，张量显著变大。为应对这个问题，需要芯片的多级缓存、带宽，AI 编译器中的前端优化、后端优化同时 runtime 库的设计思路也要有所调整。另一方面，大模型的中国汽车基础软件发展白皮书 5.0094部署中使用到了诸如 KVCache、线程管理、draft 技术等技巧，一些通用的算法技巧会被集成到模型部署的 runtime 库或部署框架中。现在各厂商团队的方案大多仍是大模型使用一套部署框架，其他模型使用过去通行的部署框架，然后通过某种通信机制协同工作。对于 AI 芯片厂商321、来说，想要自己的芯片参与大模型的异构计算，要么兼容现有的框架，要么提供面向大模型的新的部署框架，因此还会有更多与算法相关的资源调度管理方法出现。丰富的信息输入与交互：早期自动驾驶领域的 AI 模型输入的数据主要是图像数据、激光雷达数据、毫米波雷达数据，此外 GNSS（全球导航卫星系统）、IMU（惯性测量单元）、高精地图、车身状态等数据则主要是在基于规则的算法中被用到。如图 7.1-2 丰富的信息输入与交互所示，现在自动驾驶算法中要求IMU、车身状态等数据经过预处理输入模型参与融合计算。当大模型应用到自动驾驶任务之后，模型数据来源可能会来自于智驾域、座舱域、互联网，语音、文字、图像数据、外部知识322、库以及长期记忆都会成为模型输入，可以预见汽车电气电子架构从域控制器，到域融合，到中央计算，最后到车云协同的发展趋势。图7.1-2 丰富的信息输入与交互数据处理管道构建：AI 大模型训练依赖于数据质量、多样性和完整性，有效地构建和管理数据集，准确反映实际应用场景中的复杂性和多样性。在自动驾驶领域有来自摄像头、激光雷达、毫米波雷达以及GPS（全球定位系统）等多种传感器数据，高效的数据处理管道通常包括数据收集、整合、同步、预处理、特征提取、标签化和版本控制等。AI 大模型训练和推理根据需求动态调整计算资源，需要高效的资源管理和调度策略。容器化技术和容器编排工具支持模型训练的自动化和规模化。模型迭代管323、理与优化：模型迭代需要跟踪和管理不同版本的模型，便于模型的更新和回滚。分布式训练、模型压缩、模型量化等技术能够提高训练效率，减少模型的计算负担，使得 AI 模型能够更快地部署到生产环境中。通过模型剪枝和量化技术，可以显著减小模型大小，降低推理阶段的计算成本，这对于车端设备上的实时推理尤其重要。边缘计算与云端大数据层协同：边缘计算通过在网络的边缘位置部署计算资源，能够更快地响应本地数据，减少数据传输至云端的延迟和带宽消耗。在自动驾驶等场景中，大量的数据处理能够在车辆本地完成，车载计算机可以即时处理来自摄像头、雷达和激光雷达等传感器的数据，进行实时的环境感知中国汽车基础软件发展白皮书 5.0095324、和决策制定。云端拥有更强大的计算能力和存储容量，可以处理来自全球各地的海量数据，以及模型训练和优化任务。这种边缘计算与云端大数据层的协同工作模式，不仅能够提高系统的响应速度和可靠性，还能更好地保护用户隐私。2.整车软件开发方法的变革数据驱动而非规则驱动：传统软件开发方法论往往依赖于明确的规则和逻辑，开发者需要预先编写详细的程序指令来指导软件的行为。在 AI 大模型的背景下，软件开发的方式从规则驱动转向数据驱动。数据驱动的方法适用于整个软件开发生命周期，包括需求分析、设计、测试和部署等阶段。过去基于规则的自动驾驶算法通过人工设置的条件判断和参数，控制车辆在特定场景下的特定行动，但是道路场景是千变325、万化的，通过人工预设难以穷尽所有场景。在数据驱动的开发模式下，AI 通过对海量数据的学习来优化模型参数，而不依赖于预设的硬编码规则，灵活性和适应性更高，能更快地响应场景变化。在自动驾驶领域通过收集大量的驾驶数据来训练大模型，由于大模型的规模和复杂性，需要充分挖掘硬件性能，优化算法逻辑和部署策略。仿真测试效率与覆盖度提升：仿真测试是确保软件质量和可靠性的关键手段。基于 AI 的仿真环境通过大量的实车数据训练，相比传统仿真方法，能够利用机器学习算法（如深度学习）自动学习复杂系统的动态行为，无需显式编程就能模拟现实世界场景；能够根据输入数据和系统状态的变化自动调整模型参数，无需重新建模；可以处理更多326、维度的数据和更复杂的非线性关系，能够捕捉到细微模式；利用高性能计算平台和优化算法，能够实现即时或接近实时的仿真及反馈；可以通过添加更多的训练数据和微调模型来适应新的场景，更容易扩展和维护。基于 AI 的仿真环境能在汽车基础软件开发的早期阶段就发现潜在的问题，提供详细的错误报告，高精度定位错误，积累与优化测试策略方法，给出改进建议，主动式反馈机制加速修复流程，预防潜在的缺陷。AI 仿真环境以其优异的智能化水平、自适应能力、复杂度处理能力、实时性、可扩展性，敏捷且无限数量的生成真实或高度接近真实场景，覆盖极端或罕见的边界条件，降低测试成本，使系统的评估变得更加高效和全面。人类、AI 与三方工具紧密327、协作：如图 7.1-3人类、AI 与三方工具的协作所示，人类工程师收集挖掘汽车基础软件原始需求信息，而 AI 通过智能分析来辅助需求的细化和理解。标准代码库通常包含大量的功能和模块，有些功能并非全部适用于项目，通过 AI 对代码库进行智能分析，识别项目所需的特定功能和模块，按需自动生成 ARXML 文件或脚本，精简代码。自动调整配置文件能提高代码的可读性和可维护性，减少不必要的依赖，降低复杂度与出现兼容性问题的风险。生成的ARXML文件被导入到第三方工具中，用于系统设计、代码生成或测试用例的自动化、智能化生成，生成、执行测试用例，人类工程师参与设计、编码、测试规则定义和输出评审，确保软件质量及328、其稳定性。图7.1-3 人类、AI与三方工具的协作中国汽车基础软件发展白皮书 5.0096基于大模型的仿真训练：端到端的自动驾驶要求 4D 的标注数据，人工标注成本大，功效低。基于大模型的生成算法可以为仿真训练生成大量逼真 cornercase（极端情况）。当配备影子模式的车辆在道路上行驶的时候，一旦自身算法的规划控制与驾驶员的操作不一致，汽车会将当时的场景上报到云端，服务器中心通过多模态大模型分析上报的场景，生成类似场景，并执行仿真训练，然后自动化测试反馈，最后更新算法模型。相较于人工修改代码，或者重新采集标注数据，这种监督、上报、仿真的方式将大幅提升训练效率。整车协作开发更加重要：以往，不329、同域控制器和云端的开发是相互独立的。大模型或多智能体应用于全驾驶流程，要求以整车的视角协调不同功能模块的部署和协作。开发团队首先需要清晰定义不同的软件模块的优先级，哪些对实时性要求高，哪些对确定性要求高，哪些是更加灵活随机的。需要清楚大模型或智能体在规划汽车行为的时候，车上所有模块如何做好隔离和联动。生成式软件架构方法：相比传统的软件架构，生成式软件架构不必从顶层到底层逐步分解，层层定义算法、逻辑、数据、输入输出详细接口、交互流程、状态机等，只需要给出系统和软件需求，较为抽象的目标定义，AI 自动完成架构设计，自然保持设计与实现的一致性、需求到交付的一致性。通过模型训练和新创新数据训练，获得最330、优软件架构，自带继承性和创新性。（二）技术路线1.基于大模型的新型软件工艺如图 7.2-1 基于 AI 的新型软件研发体系所示，AI 驱动的软件研发体系以数据为驱动，人机高度协同，对人、机、料、法、环、测全要素重构。在超脑加持下，团队获得上帝视角，按需赋能，变革项目组织体制；以开发智能化、过程智能化、测试智能化，AI 数字员工和人类工程师主动智能协同，组装超级智能体，协作完成复杂任务；将垂直领域的技术、标准、产品、组件、代码以及实践构建为知识图谱，将软件实体以原子组件的积木化、流水线组合，快速开发软件产品；AI 接管重复性的工程活动、管理活动和品控活动，让人类工程师专注于更高层次的设计和创新；331、搭建个性化、最佳、最适动态开发环境与数字车模拟环境，缩短开发周期；全面 AI 感知与反馈闭环有助于及时发现潜在的风险与优化资源分配，提高交付质量。图7.2-1 基于AI的新型软件研发体系中国汽车基础软件发展白皮书 5.00971.1 人：项目组织体制的深度变革在超脑的感知、理解、推理、计算、度量、预测与预警能力的加持下，团队获得上帝视角，按需为各层级、专业、系统、岗位赋能。如图 7.2-2 基于 AI 的新型软件开发组织所示，新型软件开发组织相比传统软件开发金字塔组织结构，给项目管理体制带来重大变革：在新型软件开发组织中，AI 将协作顶层企划团队产品方案制定、技术质量规划、项目管理策略制定；为332、中层平台团队在平台设计、平台构建提供助手，助力中高级工程师，拓展能力边界，提高有效产出；以自动化工具与工作流方法，大量取代初级工程师，可靠高效地完成软件开发任务。自顶向下的信息传递和自下而上的执行反馈形成闭环，更高效的任务分发与均衡调度、任务执行与绩效反馈，确保开发过程的透明性和可控性。图7.2-2 基于AI的新型软件开发组织1.2 机：智能体深度参与软件工程智能体是一种能够自主地观察环境、自我决策并自主地执行特定任务的软件实体。如图 7.2-3 智能体深度参与软件工程所示，智能体如同员工与其他智能体或人类工程师进行交互和协作。精心设计的智能体能够执行复杂的、通常需要人类经验和专业技能的任务，333、同时保持高度的准确性和效率。开发智能体（如代码生成、代码审查、代码重构）、测试智能体（如测试用例、组件测试、自动化测试）、过程智能体（如QCD 监控、需求管理、风险管理）等作为 AI 数字员工，深度参与软件工程，与人类工程师协同工作，提高软件开发的效率和质量。智能体通过自学习、自适应、交互协作，完成从场景到交付，从创意到实现，从目标到解决方案的复杂任务。人类工程师可以专注于更复杂和创新的任务。图7.2-3智能体深度参与软件工程中国汽车基础软件发展白皮书 5.00981.3 料：知识库与组件化改进编程能力用大模型技术整合技术、标准、产品、组件、代码以及最佳实践等元素，将编程语言、中间件、API 接口、微服务、框架、功能代码、设计模式、解决方案、经验总结等提取知识库、知识图谱，高效地管理和利用现有的技术和资源。基于项目与产品实践，使用知识萃取技术，将汽车电子基础软件的设计、代码和用例提取为模块