中国汽车基础软件发展白皮书3.0阅读版(4)

1 .中国汽车工业协会 中国汽车基础软件生态委员会（AUTOSEMO） 地址: 北京市丰台区汽车博物馆东路诺德中心11号楼33层 邮政编码：110160 联系电话: 010-63979900 邮箱: autosemo-info@caam.org.cn 网址: www.autosemo.com 中国汽车基础软件 发展白皮书 3.0 2022 指导单位：工业和信息化部装备工业一司 工业和信息化部装备工业发展中心 发布单位：中国汽车工业协会软件分会 中国汽车基础软件生态委员会 (AUTOSEMO) 

2 . 序言 P R E F A C E 当前，中国汽车产业正处于由大向强的伟大历史转折进程中，在供给侧和需求侧的双向推动 下，汽车产业正由功能时代向智能时代演进，汽车产业新格局正在加速形成。我国汽车产销总量 已连续 13 年位居全球首位，并在 “电动化、网联化、智能化” 等方面取得了巨大的进步，进一 步巩固了我国作为汽车大国的地位。随着我国智能汽车产业的迅猛发展，用户体验驱使 OEM 不 断变革，正经历由 “以车为中心” 到 “以用户为中心” 的转型。因此，如何为主机厂赋能、创造 汽车产品的新价值，成为行业共同思索的话题。 在此过程中，汽车行业将更加聚焦于智能化和网联化。深化融合创新、提高基础软件应用能 力、加快车用操作系统等关键技术攻关和产业化落地已成为中国汽车基础软件发展的重中之重。 通过生态搭建能够快速建立汽车产业不断与互联网、道路交通、基础设施等能力融合，实现跨车 内各域、跨车云、连接 IoT 的跨软件平台建设，构建协同运行机制，高效配置基础软件科技力量 和创新资源，强化跨领域的协同攻关能力。同时，在智能化、网联化发展过程中加强产业链上下 AUTOSEMO 游合作，共建开放生态，使能万物互联，以推动新技术新产品的进一步完善与发展。 2022 年 9 月，全国政协经济委员会副主任、工业和信息化部原部长苗圩在全球新能源与智 能网联汽车供应链创新大会上指出，操作系统是比芯片更加迫切和致命的问题，是决定汽车智能 化、网联化胜负的关键。在开放前提下要允许多路径并存，为车用操作系统企业预留试错空间， 鼓励探索不同技术路线，通过市场检验出最适合的国产操作系统。本年初，工业和信息化部装备 工业一司王卫明司长在新闻发布会上指出，需积极应对汽车芯片短缺，组建汽车半导体推广应用 工作组，加快推进整车信息安全、软件升级、数据记录等标准的制定，加速产业化进程。因此我 们有使命推动电子电气架构的发展，打造本土化的、可大规模应用的自主智能网联汽车车用操作 系统，开发应用国产高水平的智能大算力芯片，为 OEM 赋能，为我国汽车产业贡献力量。行业 需要打破传统的封闭式开发模式，通过国团标及创新技术研发建立统一的认识，避免汽车软件领 域的 “卡脖子” 风险，加快推进以中国智能汽车基础软件为核心的生态建设。同时，在行业内加 强推广应用，真正打破汽车行业软件垄断，构建自主汽车软件知识产权体系，赋能中国汽车产业， 使其真正成为具有全球竞争力的产业。 清华大学教授 中国工程院院士 2022 年 9 月 18 日 

3 .前言 本次《中国基础软件白皮书 3.0》 （下文简称《白皮书 3.0》）是继 2021 年《白皮书 1.0》 发布之后，在工业信息化部装备一司和装备中心的指导下第三次发布中国汽车基础软件白 皮书。 在中国汽车行业发展的关键时期，《白皮书 3.0》联合中国汽车芯片产业创新战略联盟 以及 AUTOSEMO 80 余家成员单位，根据各家在生态领域积累的经验，结合目前汽车软 件产业发展现状，以智能汽车车用基础软件平台为主题，围绕中国汽车基础软件领域中的 关键技术和关键标准研究进展进行总结。本书内容涵盖市场发展情况，关键汽车软件技术 趋势、关键标准研究情况、汽车软件产业生态发展建议等方面。旨在鼓励行业内的技术交 AUTOSEMO 流学习，实现汽车基础软件的应用及传播，并在行业中形成统一的认知。 希望借此书，能和各行业内单位共同探讨基础软件技术发展、生态建设、人才培养等 关键问题。旨在承担中国汽车产业变革中的生态发展任务，为将来具有多要素、多维度、 多层次的更加错综复杂的汽车产业做出贡献。 —— AUTOSEMO 执行办公室 2022 年 9 月 

4 .中国汽车基础软件发展白皮书 3.0 目录 CONTENTS 第 1章 智能汽车车用基础软件平台概述 1.1 智能汽车车用基础软件平台的定义与分类�����������������������001 1.1.1 智能汽车车用基础软件平台定义������������������������001 1.1.2 智能汽车车用基础软件开发平台分类����������������������001 1.2 智能汽车车用基础软件开发平台的要素������������������������002 1.2.1 嵌入式软件���������������������������������002 1.2.2 开发方法论���������������������������������003 1.2.3 配套工具链���������������������������������003 1.3 智能汽车车用基础软件平台发展现状�������������������������004 AUTOSEMO 1.3.1 大众 VW·OS��������������������������������004 1.3.2 丰田 Arene·OS�������������������������������005 1.4 白皮书内容简介����������������������������������005 第 2章 智能汽车车用基础软件的内核和中间件 2.1 AUTOSAR CP����������������������������������007 2.1.1 技术形态����������������������������������007 2.1.2 技术发展趋势��������������������������������010 2.1.3 关键技术解读��������������������������������011 2.1.4 典型应用案例��������������������������������014 2.2 AUTOSAR AP����������������������������������017 2.2.1 技术形态����������������������������������017 2.2.2 技术发展趋势��������������������������������019 2.2.3 关键技术解读��������������������������������021 2.2.4 典型应用案例��������������������������������021 2.3 操作系统内核�����������������������������������024 2.3.1 操作系统内核技术架构����������������������������024 2.3.2 技术发展趋势��������������������������������025 2.3.3 关键技术解读��������������������������������026 2.3.4 典型应用案例��������������������������������037 I 

5 . 中国汽车基础软件发展白皮书 3.0 2.4 虚拟化��������������������������������������039 2.4.1 技术形态 ����������������������������������040 2.4.2 技术发展趋势��������������������������������041 2.4.3 关键技术解读 ��������������������������������044 2.4.4 典型应用案例��������������������������������048 第 3 章 智能汽车车用基础软件平台 3.1 基础软件开发平台���������������������������������052 3.1.1 基于功能软件的自动驾驶平台�������������������������052 3.1.2 基于 ASF 的生态框架�����������������������������057 3.2 基础软件验证平台���������������������������������062 3.2.1 验证平台概要��������������������������������062 3.2.2 验证平台典型案例������������������������������063 第 4 章 智能汽车车用基础软件平台关联技术 AUTOSEMO 4.1 功能安全与基础软件��������������������������������075 4.1.1 相关标准介绍��������������������������������075 4.1.2 功能安全软件架构������������������������������078 4.1.3 内存分区静态分析技术解读��������������������������083 4.1.4 工具链的功能安全要求����������������������������084 4.2 信息安全与基础软件��������������������������������086 4.2.1 相关标准介绍��������������������������������086 4.2.2 信息安全软件架构������������������������������089 4.2.3 关键技术解读��������������������������������090 4.3 数据管理与基础软件��������������������������������094 4.3.1 汽车数据智能背景介绍����������������������������094 4.3.2 基于边缘计算的嵌入式车端数据管理系统��������������������100 4.3.3 数据驱动能力分级������������������������������104 4.4 开发模型与基础软件��������������������������������105 4.4.1 双态敏捷开发模型������������������������������105 4.4.2 自动化编译框架�������������������������������108 4.4.3 持续集成持续交付������������������������������111 4.5 车载通信技术�����������������������������������115 4.5.1 SOME/IP����������������������������������115 4.5.2 DDS������������������������������������123 II 

6 .中国汽车基础软件发展白皮书 3.0 4.6 车载芯片技术�����������������������������������126 4.6.1 国内本土化芯片发展现况���������������������������126 4.6.2 关键硬件技术��������������������������������127 第 5章 国产基础软件生态介绍 5.1 基础软件�������������������������������������135 5.2 基础软件平台�����������������������������������136 5.3 自动驾驶�������������������������������������137 5.4 操作系统�������������������������������������138 5.5 车云一体化������������������������������������139 5.6 信息安全�������������������������������������139 5.7 工具链��������������������������������������140 第 6章 国产基础软件问题与展望 AUTOSEMO 6.1 加快技术发展创新���������������������������������141 6.2 完善生态体系构建���������������������������������141 6.3 提升信息安全和数据安全能力����������������������������142 6.4 重视复合型人才培养��������������������������������142 第 7章 主要贡献单位 III 

7 .中国汽车基础软件发展白皮书 3.0 第1章 智能汽车车用基础软件平台概述 基于一个整车平台，车企可以衍生出多款车型，从而全面提升硬件资源的复用性。纵观汽车工业的 发展历程，平台化是驱动汽车行业高速发展的关键，它不仅有利于突破复杂技术、提升产品的可靠性和一 致性，还有利于降低研发成本、缩短开发周期。 随着汽车 E/E 架构的升级和智能网联汽车的快速发展，对汽车软件的迭代更新提出了更高要求。因此， 打造车用一体化软件平台是车企实现软件定义汽车战略布局的重中之重。 白皮书 3.0 旨在分析汽车基础软件平台及其关联技术的发展趋势，除了对其技术形态做一般性定义 之外，还进一步解读了其中的关键技术、分析了典型应用案例，帮助产业链参与者对智能汽车车用基础软 件平台的技术形态和发展趋势产生更多思考。 1.1 智能汽车车用基础软件平台的定义与分类 1.1.1 智能汽车车用基础软件平台定义 汽车软件主要分为应用软件和基础软件。应用软件和业务形态高度关联，不同控制器的应用软件之 AUTOSEMO 间差异较大。基础软件介于应用软件和硬件之间用于屏蔽硬件特性、支撑应用软件，可有效地实现应用软 件与硬件之间解耦，非常适合平台化最终形成基础软件平台。 车用基础软件开发平台和车用基础软件验证平台在汽车软件中的位置如图 1.1-1 所示。基础软件平 台又可以进一步分为基础软件开发平台和基础软件验证平台。其中，基础软件开发平台包含内核、虚拟化 模块，中间件，功能软件以及与之相配套的开发工具链，用于支撑应用软件的快速迭代开发。基础软件 验证平台通过调试、分析、仿真、测试等手段验证设计和实现的一致性。 车用基础软 车用基础软 件 开发平 台 件验证平台 图1.1-1 汽车软件构成 白皮书着重讲述基础软件开发平台，仅在部分章节对基础软件验证平台进行介绍。 1.1.2 智能汽车车用基础软件开发平台分类 2019 年 10 月，汽标委发布了《车用操作系统标准体系》，参考该标准可以类似地将智能汽车车用 基础软件开发平台分为安全车控基础软件开发平台、智能驾驶基础软件开发平台和车载信息娱乐基础软件 开发平台。 001 

8 . 中国汽车基础软件发展白皮书 3.0 1. 安全车控基础软件开发平台 安全车控基础软件开发平台主要面向车辆经典控制领域，如动力系统、底盘系统和车身系统等，该类 基础软件开发平台对实时性和安全性的要求极高。目前，主流的安全车控基础软件开发平台兼容 OSEK/ VDX 或 Classic AUTOSAR 标准，其功能安全等级需要达到 ASIL-D。 2. 智能驾驶基础软件开发平台 智能驾驶基础软件开发平台主要面向智能驾驶领域，用于智能驾驶辅助，以及全自动驾驶功能的控 制器上。目前智能驾驶控制器主要使用的底层操作系统有 QNX 以及 Linux。 与安全车控基础软件开发平台相比，对智能驾驶基础软件开发平台的要求主要体现在： l 强大的计算能力，以满足图像识别和决策计算的要求 l 强大的数据吞吐能力，以满足多传感器数据的实时接入和处理要求 l 高度的灵活性、扩展性、可编程性，以满足多种算法模型的需要 l 易用性，以满足 ADAS 和自动驾驶算法所需调试、调优、调测的需要 当前异构分布硬件各单元所要求的功能安全等级有所不同，AI 单元需要达到 QM 至 ASIL-B，计算单 元需要达到 QM 至 ASIL-D。 中国软件测评中心 2019 年发布的《车载智能计算基础平台参考架构 1.0》就是智能驾驶基础软件开 发平台的一个重要参考。 3. 车载信息娱乐基础软件开发平台 AUTOSEMO 车载信息娱乐基础软件开发平台主要为车载信息娱乐服务以及车内人机交互提供控制平台，是汽车 实现座舱智能化与多源信息交互的必要运行环境。 车载信息娱乐基础软件开发平台对于实时性、安全性、可靠性的要求处于中等水平，既可以使用 An- droid、Linux 等非实时操作系统，也可以使用 QNX、VxWorks 等实时操作系统。为便于应用程序移植，当 前越来越多的车载信息娱乐基础软件开发平台采用 Android Automotive OS 或其他类 Linux 系统。 随着车辆由单纯的交通工具向智能移动终端转变，车载信息娱乐基础软件开发平台需要满足如下 要求： l 支持多样化应用，满足支付、娱乐、导航、信息服务等多样化功能需求 l 支持多生态资源，将手机端庞大的信息娱乐服务生态资源，通过采用相同或类似的操作系统，快 速移植到车辆智能终端，避免重复开发 l 安全，通过深度定制达到车辆信息安全和功能安全的标准 1.2 智能汽车车用基础软件开发平台的要素 基础软件开发平台的要素分为嵌入式软件、开发方法论和配套工具链。 1.2.1 嵌入式软件 嵌入式软件是基础软件开发平台的基本组成部分，需要满足功能实现要求和功能安全要求。 一是标准化 / 可扩展的功能实现。标准化 / 可扩展的功能实现既要充分满足整车应用对基础软件开 发平台的功能需求，又要充分考虑这些功能需求的标准化 / 可扩展性。总结和归纳共性的需求，基于共 性需求参考和借鉴国内外的优秀案例，充分考虑未来汽车基础软件的发展趋势，提出更加成熟的软件设 计并将其标准化。标准化可以推动基础软件开发平台的推广，可扩展可以支撑基础软件开发平台的发展。 二是符合功能安全要求。基础软件开发平台支撑着整车应用的实现，如果不能守护好安全这道大门， 002 

9 .中国汽车基础软件发展白皮书 3.0 后果不堪设想。ISO26262（2018）对基础软件开发过程的各个阶段提出了充分的要求和建议，可以作 为基础软件开发平台开发的准则和指导。 1.2.2 开发方法论 开发方法论是基础软件开发平台的重要组成部分。清晰的开发方法论可以最大程度发挥出基础软件 开发平台的优势。开发方法论应该包含与内外部开发环境的交互规则和详细的使用说明。 交互规则不仅定义了基础软件开发平台内部之间的交互规则，还定义了基础软件开发平台与应用软 件、其他开发工具之间的交互规则，以便基础软件开发平台可以与其他开发环境更好地兼容与交互。详 细的使用说明可用于指导用户合理、安全地使用基础软件开发平台来实现所需的整车功能。以 AUTOSAR CP 开发方法论为例，图 1.2-1 展示了从系统层级配置到 ECU 可执行文件生成的过程以及该过程中的文 件交互。白皮书 2.1 AUTOSAR CP 一章会对该方法论进行详细说明。 AUTOSEMO 1.2.3 配套工具链 图1.2-1 AUTOSAR CP 方法论概览 配套工具链是基础软件开发平台的必要组成部分。使用工具链自动生成基础软件开发平台的配置代 码可以减少编码成本、提高软件质量、统一软件风格、降低设计难度。工具链需要满足安全稳定、易用、开 放完整的要求。详见图 1.2-2。 基础软件开发平台工具链 图1.2-2 基础软件开发平台工具链设计要求 003 

10 . 中国汽车基础软件发展白皮书 3.0 安全稳定是工具链的第一要务。通过强化高功能安全、高网络安全等能力，对全链路的数据处理、原 型搭建、算法开发、信息标准化等流程进行强有力的保证，保障基础软件开发平台应用开发全流程的安全 稳定。 易用性是衡量工具链价值的重要指标。其包括合理的界面设计、功能模块的独立解耦、自动代码的生 成能力、图形化配置的能力等。 开放完整是提高开发效率的重要保证。工具链需要 ：配合基础软件开发平台对新技术新功能不断开 放创新；需要面向不同垂直应用领域提供开放的场景模型库；需要兼容不同 OEM 的应用场景及第三方应 用软件开发 ；需要通过工具链的开放生态助力基础软件开发平台的生态化发展。工具链的完整性不仅是 单一业务场景下的功能完整，更是覆盖全流程的完整。以自动驾驶为例，工具链需要覆盖从算法模型训 练到芯片运行模型预测的完整 AI 开发过程，并通过其开放性不断丰富自动驾驶应用场景库以加快开发速 度、保证开发质量。 1.3 智能汽车车用基础软件平台发展现状 国内外主机厂、造车新势力、零部件供应商等都在着力打造其专属的基础软件平台，并已形成以 OS 为核心向基础软件平台进化的趋势。此处挑选两个国外主机厂基础软件开发平台的案例进行介绍，国内 发展现状将在第 6 章中介绍。 1.3.1 大众 VW · OS AUTOSEMO 2019 年 6 月，基于汽车智能化和汽车新商业模式的需求，大众汽车宣布成立 Car·Software 软件部门， 专门从事自主软件平台 VW · OS 的研发。计划于 2025 年，旗下所有新车型均搭载 VW · OS，以实现车 辆传统控制系统、ADAS 系统、车载娱乐 / 互联系统、能源管理系统和车辆舒适系统的全面整合。 VW · OS 是集成了 POSIX OS、Adaptive AUTOSAR、VW API 的一体式 SOA 平台，用于大众全新集 中式 E/E 架构 ICAS。其中 Adaptive AUTOSAR 的实现采用了 EB xelor 高性能计算软件平台（基于 AU- TOSAR AP R19-03 标准 )。目前该平台已实现在大众 ID.3 系列车型上的搭载。大众 VW·OS 如图 1.3-1 所示。 图1.3-1 大众VW·OS 004 

11 .中国汽车基础软件发展白皮书 3.0 1.3.2 丰田 Arene · OS 为了更好地应对软件定义汽车的发展需求，2021 年 8 月丰田宣布将在未来五年内打造整车软件平 台 Arene · OS，以实现在不影响车辆安全的前提下，借助其开放的车辆应用程序编程接口和软件工具包， 完成汽车软件的快速迭代，从而缩短汽车软件开发和部署的周期。 丰田 Arene · OS 软件平台如图 1.3-2 所示，其主要包括软件工具包和 Arene API 车辆应用程序编 程接口。其中软件 Arene API 采用 Rust 语言编写，作为预编译的 C/C++ 库被部署在车辆内的接口 ECU 上，并可实现跨平台部署。Arene · OS 软件工具 / 服务包括 APP SDK（用于开发、测试和部署应用到虚 拟设备或者真实车辆的工具和 API）, 虚拟仿真 / 测试平台（支持虚拟场景创建、软件在环和硬件在环仿真） 和基础开发环境（采用基于云的数据管道技术，结合可自动创建 AWS 沙箱的 Ansible 和 Terraform 模板 来实现数据处理和索引）。借助 Arene · OS 的车辆抽象层 , 开发者可以将相同的源代码部署到任何运行 Arene · OS 的车辆，从而提升软件的复用性。 AUTOSEMO 图1.3-2 丰田Arene·OS 与此同时，国内基础软件平台的发展呈现出百花齐放、欣欣向荣的态势，但是其中也存在一些痛点和 问题。例如在安全车控基础软件平台方面，本土化问题也越来越突出，不少控制器开发还是基于国外的 解决方案 ；在智能驾驶基础软件平台方面，还存在多处 “卡脖子” 技术短板，尚未出现足够成熟的解决 方案并且缺乏实时安全的内核、中间件和虚拟化产品；在车载信息娱乐基础软件平台方面，内核种类繁多， 业内供应商各自为战，尚未形成合力。 1.4 白皮书内容简介 白皮书围绕智能汽车车用基础软件平台及其关联技术展开。 第 2 章智能汽车车用基础软件及操作系统分别从技术形态、技术发展趋势、关键技术解读、典型应用 005 

12 . 中国汽车基础软件发展白皮书 3.0 四个方面对基础软件开发平台的重要组成部分 CP AUTOSAR、AP AUTOSAR、操作系统内核、虚拟化进 行介绍。 第 3 章智能汽车车用基础软件平台分别介绍了基于功能软件的自动驾驶平台和基于 ASF (AU- TOSEMO Service Framework) 的生态框架，说明了其组成部分和适用场景。 第 4 章智能汽车车用基础软件开发平台关联技术以六个技术领域为切入点，分别研究了基础软件平 台对支撑功能安全所起的作用 ；研究了基础软件开发平台对支撑信息安全所起的作用 ；研究了边缘计算 如何更好地驾驭数据以支撑车企数字化转型 ；研究了双态开发模型和持续集成持续发布 CI/CD 如何支撑 基础软件开发平台的高效开发 ；研究了几种主流支撑 SOA 的先进车载通信技术 ；研究了车载芯片的发展 趋势及其关键技术。 第 5 章国产基础软件生态介绍描述了国产基础软件生态的发展现状。 第 6 章国产基础软件问题与展望对基础软件平台的未来发展提出了建议。 AUTOSEMO 006 

13 .中国汽车基础软件发展白皮书 3.0 第2章 智能汽车车用基础软件的内核和中间件 本章节分别从技术形态、技术发展趋势、关键技术解读、典型应用四个方面对基础软件开发平台的重 要组成部分 AUTOSAR CP、AUTOSAR AP、操作系统内核、虚拟化进行介绍。 2.1 AUTOSAR CP 2.1.1 技术形态 AUTOSAR CP 是 Classical Platform AUTOSAR 的简称，广泛用于对实时性、安全性要求高的动力 域控、底盘域控、车身域控等方面，以达到软硬件解耦、提高开发效率、提升软件复用性等目的。AUTO- SAR CP 规范不仅提出了软件分层架构，而且定义了基于该规范的标准开发流程，即开发方法论。下面从 开发方法论、软件分层架构、工具链这三方面详细说明。 1. 开发方法论 AUTOSAR CP 为基于该规范的系统开发提供了一个通用的技术方法。它定义了从系统开发到单个 ECU 开发的各个阶段，以及在各个阶段需要完成的工作内容、需要提供的成果物。开发一个系统可分解 AUTOSEMO 为以下四个阶段。 一、开发抽象系统描述和基于 VFB( 虚拟功能总线，它描述了系统中所有 SWC 之间的交互关系，与 ECU 个数和网络拓扑无关）的系统描述，如图 2.1-1 所示。该阶段首先基于功能提出对整个系统的技术 要求和约束条件，并且从功能视角设计合理高效的系统架构。其次，工程师在车辆电子电气架构尚未确 定之前就开始基于 VFB 进行系统架构设计，将功能视角的系统架构转为 VFB 视角的系统架构。 图 2.1-1 抽象系统描述与基于VFB的系统描述 二、开发系统和子系统，如图 2.1-2 所示。该阶段将整车的电子电气架构作为输入，结合网络拓扑和 硬件资源情况将 VFB 视角的 SWC 分配到各个 ECU，并且将 VFB 的接口转换成能够在通信总线上传输的 数据，最后生成 System Extract 和 ECU Extract 供 ECU 软件集成时使用。 007 

14 . 中国汽车基础软件发展白皮书 3.0 图 2.1-2系统和子系统开发 三、开发应用软件和基础软件。在 VFB 视角的系统架构设计完毕后，即可进行原子级 SWC 开发包括 AUTOSEMO 实现其内部行为，无需关心具体 ECU 信息。另一方面，在系统和子系统设计完成后，即可进行基础软件开发。 因为基础软件独立于 VFB，所以只要在 ECU 软件集成前完成开发即可。 四、ECU 软件集成。当 ECU Extract、基础软件、原子级 SWC 都开发完成后即可进行 ECU 软件集 成。在该阶段工程师定义好 Schedule Table，将 SWC Runnable 分配到 task 中、补充基础软件配置、生 成 RTE 后即可编译链接生成可执行文件。 总的来说，该方法论将汽车嵌入式软件开发分为系统架构级、ECU 级和 SWC 级。系统架构级开发可 进行整车级别的软件架构设计以及相关功能模块的定义。ECU 级开发则着重开发单片机底层软件。SWC 级开发则主要开发具体控制算法。各级开发可以并行，不同的开发之间通过标准化的 ARXML 文件进行 交互。 2. 软件分层架构 在 AUTOSAR CP 分 层 架 构 中， 自 上 而 下 分 别 为 应 用 软 件 层（Application Layer）、运 行 时 环 境 （Runtime Environment）、基础软件层（Basic Software Layer）, 如图 2.1-3 所示。 应用软件层包含若干个软件组件，软件组件间通过端口进行交互。每个软件组件可以包含一个或者 多个运行实体，运行实体中封装了相关控制算法，其运行可由 RTE 事件触发。 运行时环境作为应用软件层与基础软件层交互的桥梁，为软硬件分离提供了可能，是 VFB 的具体实现。 RTE 可以实现软件组件间、基础软件间以及应用软件组件与基础软件之间的通信。RTE 封装了基础软件 层的服务、提供了标准化接口，使得应用软件层可以通过 RTE 接口调用基础软件服务。此外 RTE 抽象了 ECU 之间的通信，即 RTE 使用标准化接口将 ECU 之间的通信抽象为软件组件之间的通信。 基础软件层又可分为四层，包括服务层、ECU 抽象层、微控制器抽象层和复杂驱动。各层又由一系列 基础软件组件构成，包括系统服务、存储服务、通信服务等，它们主要用于提供标准化的基础软件服务。 008 

15 .中国汽车基础软件发展白皮书 3.0 AUTOSEMO 图 2.1-3 AUTOSAR CP软件分层架构 服务层提供了汽车嵌入式系统软件常用的一些服务，包括系统服务、存储服务以及通信服务三大部分。 还提供包括网络管理、存储管理、模式管理和实时操作系统等服务。ECU 抽象层与 ECU 平台相关，但与 微控制器无关，包括板级硬件抽象、存储硬件抽象、通信硬件抽象和 I/O 硬件抽象。该层将 ECU 结构进 行了抽象，负责提供统一的访问接口，实现对通信、存储器或者 I/O 的访问，从而不需要考虑这些资源 是由微控制器片内还是片外提供的。微控制器抽象层是实现不同硬件接口统一化的特殊层，包括微控制 器驱动、存储驱动、通信驱动以及 I/O 驱动。通过微控制器抽象层可将硬件封装起来，避免上层软件直接 对微控制器的寄存器进行操作。最后，由于对复杂传感器和执行器进行操作的模块涉及严格的时序问题， 难以抽象，所以在 AUTOSAR CP 规范中没有被标准化，统称为复杂驱动。 如上所述，AUTOSAR CP 良好的分层架构为软硬件之间解耦、软件模块之间解耦提供了坚实的保障。 3. 工具链 V 模型是目前汽车电子软件开发过程中采用的主流开发模式，V 模型左侧统称为设计阶段，主要涵 盖业务需求分析（Requirement Analysis）、系统设计（System Design）、架构设计（Architectural De- sign）、模块设计（Module Design）和编码（Coding）五个阶段。V 模型右侧统称为测试阶段，涵盖单元 测试（Unit Testing）、集成测试（Integration Testing）、系统测试（System Testing）和验收测试（Ac- ceptance Testing）四个阶段。在 V 模型左侧，当前主流商用工具链可以全面支撑 AUTOSAR CP 开发方 法论中提到的系统架构级、ECU 级和 SWC 级开发，详细请参考图 2.1-4 AUTOSAR CP 工具链。 009 

16 . 中国汽车基础软件发展白皮书 3.0 图 2.1-4 AUTOSAR CP工具链 AUTOSEMO 参照 AUTOSAR CP 方法论和开发流程，开发工具主要分为以下四类： 一、系统设计工具。一般由 OEM 使用，主要用于完成软件组件框架（端口、端口接口、数据类型、运 行实体、触发事件）的设计及框架代码生成 ；实现软件组件间通信端口的连接 ；导入 DBC、LDF 等传统 网络描述性文件实现软件组件向 ECU 映射等工作。 二、软件组件设计工具。一般由 Tier1 使用，主要用于软件组件框架的搭建，生成符合 AUTOSAR 规 范的代码与软件组件 ARXML 文件。之后将 ARXML 文件导入 Matlab Simulink 后可继续进行控制算法模 型开发，开发完成后通过自动代码生成获得的 C 代码将用于 ECU 软件集成。 三、MCAL/BSW 配置及 RTE 代码生成工具。MCAL 配置工具主要用于底层驱动的配置与配置代码 生成、BSW 配置工具主要用于基础软件协议栈的配置与配置代码生成，生成后的配置代码需要与工具供 应商提供的静态代码一同进行 ECU 软件集成。RTE 代码生成工具以软件组件 ARXML 或基础软件配置 ARXML 为输入，生成符合 AUTOSAR CP 标准的 RTE 代码，向软件组件提供可靠的通信和调度服务。 四、编译与调试工具。用于 ECU 软件集成时的编译与调试。由于 AUTOSAR CP 工程代码量十分庞大， 所以对编译器和调试器的要求也相对较高。 此外，目前市面上的 AUTOSAR 工具链都是桌面应用程序，这使工具链的维护和升级都不方便，并 且由于应用程序在各个电脑上都是独立的，所以其资源是不可共享的，使开发效率降低。而随着 5G 和 千兆网络的普及，在未来，AUTOSAR 工具链由桌面应用程序发展为 Web 应用程序成为可能。具有超大 带宽、超低时延、更加稳定可靠等特征的宽带网络结合超强性能的 Web 应用程序服务器，以及 Web 应用 程序本身的优势，这使得工具链供应商可以更加方便的维护及更新工具，开发者们更加高效、友好的合作 开发。 2.1.2 技术发展趋势 AUTOSAR CP 发展历史悠久，从诞生到现在已经有近 20 年的历史。本章节将从当前痛点分析角度 010 

17 .中国汽车基础软件发展白皮书 3.0 来阐述 AUTOSAR CP 存在的问题和未来发展趋势。 AUTOSAR CP 带来的优势和便利前文已经叙述了很多，但是它也不是完美的，在实际应用过程中也 存在一些问题，下面将从五个方面分别阐述。 一、架构充分解耦导致标准和接口规范繁多。不可否认 AUTOSAR CP 的规范文档非常详尽，但正是 两百多个多达几万页的标准文档让一些传统的嵌入式工程师望而止步。同时 AUTOSAR CP 提出了很多新 概念，比如标定量通过描述文件进行描述 ；应用接口不通过传统全局变量的方式与底层软件交互，而是 对接口进行描述定义通过 RTE 统一接口进行匹配等。AUTOSAR CP 的软件开发理念和传统嵌入式工程 师的认知偏差也是其普及率不高的原因之一。 二、工具链价格昂贵国产研发之路任重而道远。动辄几百上千万的软件使用授权费对 OEM、Tier1 来 说都是很大的研发投入。尽管国内已经有普华基础软件、经纬恒润、东软睿驰、中汽创智等几家供应商开 始布局工具链的开发，但国产工具链的研发推广之路依然任重而道远。 三、工具链之间兼容性差影响合作开发的灵活性。在实际项目中并没有体现出 AUTOSAR CP 软件模 块的复用性和独立性。由于各厂商对 AUTOSAR CP 规范的理解并不完全一致，而且各厂商的工具也并不 完全兼容，导致 OEM 集成各家供应商开发的软件模块需要花费大量的精力和时间。原本希望借助 AU- TOSAR CP 标准统一的优势合作开发，但是因为工具链的兼容性问题而不得不统一工具链的使用，严重 限制了合作开发的灵活性。 四、自动化程度低导致开发和集成效率偏低。基础软件与应用软件的接口集成需要大量的手动配置工 AUTOSEMO 作，不仅操作上低效出错率高，而且在错误检查方面也不如传统软件集成方便。对于某些错误提示往往 不能快速定位错误原因，对于某些需求追加或变更往往不能快速对应。针对这一痛点，国内大部分 OEM 都已经开始使用自动化脚本工具直接操作 ARXML 来代替这种重复性的工作。 五、代码可读性差导致调试困难。这是代码生成工具普遍存在的问题，和 MATLAB 的 AUTOSAR 工 具箱生成的代码一样，一些 AUTOSAR 工具链的 RTE 代码生成工具生成的代码可读性也较差，这给软件 调试带来了不少麻烦。例如在调试基于 SOMEIP 的服务通信时需要根据服务请求信号、提供信号的数据 流向和函数调用关系，一层一层地查询才能理解整个通信过程。 2.1.3 关键技术解读 1. 基础软件多核分配 基础软件多核分配是发挥多核系统并行计算、负载均衡、快速响应优势的关键技术。没有基础软件的 多核分配，就算应用软件做了多核分配，多核系统的优势将受到核间通信效率的制约，甚至系统整体性 能还不如单核。实现基础软件多核分配的主要技术手段有主卫星方式（Master/Satellites）和通信协议栈 分割（Com-Stack Split）两种。 一、主卫星方式。如图 2.1-5 主卫星方式的基础软件分割所示，该方式可适用于 Dem、FiM、WdgM、 Com、NvM、XCP、EcuM 等基础软件组件。当这些组件提供的服务需要被多个核使用时可以考虑主卫星 方式，即卫星给其所在核的其他模块提供服务接口并将收到的服务请求通过主卫星通信传递给主星，主 星协调、过滤和接收各卫星的服务请求并进行处理，最后将处理结果通过主卫星通信反馈给卫星。由于主 卫星之间的工作分配 AUTOSAR CP 并未标准化，所以用户可自定义。一种极端情况是主星具备全部功能， 卫星仅为同核其他模块提供服务接口并将服务请求转发到主星上处理 ；另一种极端情况是卫星和主星一 样具备全部功能并不需要主星处理服务请求，它只需要与主星保持必要信息的同步。 011 

18 . 中国汽车基础软件发展白皮书 3.0 图 2.1-5 主卫星方式的基础软件分割 由于卫星提供的接口可以被该核的其他模块直接调用并通过高效的主卫星通信与主星交互，从而避 免了低效的 Client/Server 通信，大大提高了多核系统中基础软件的服务效率。另外由于主卫星可并行处 理服务请求，因此 CPU 负载可以被有效平衡、基础软件的服务速度也得到提高。 二、通信协议栈分割方式。该方式通过一个增强型的 PduR 引入 FIFO 队列（无需自旋锁）或 Buffer（需 要配合自旋锁）这样的数据结构对跨核 PDU 进行路由，可将不同类型的总线协议栈分配到不同的核，如 AUTOSEMO 将 CAN 协议栈和以太网协议栈分配到不同的核。通过这样的协议栈分割可达到 CPU 负载均衡及提升多 核系统实时性的目的。 2. 软件集群技术 软件集群（Software Cluster）在 R20-11 版本中被首次提出，是 AUTOSAR CP 在软件架构方面的 一次创新，其本质是利用二进制接口技术实现更为灵活的软件集成与更新。 图 2.1-6 软件集群技术示例 012 

19 .中国汽车基础软件发展白皮书 3.0 如图 2.1-6 软件集群技术示例所示，通过软件集群技术 AUTOSAR CP 软件架构被分割成了两个独 立的软件集群，分别为应用软件集群（Applicative Software Cluster）和主软件集群（Host Software Cluster）两部分。其中应用软件集群可以单独编译，其搭载一组关联度较高的 SWC ；主软件集群也可以 单独编译，其除了可以搭载 SWC 之外还必须搭载基础软件（包含 OS 和 MCAL）。一个控制器中可以存 在多个高度解耦的应用软件集群，但是只能且必须存在一个主软件集群，分别将应用软件集群和主软件 集群烧写至目标板后即可形成完整的、可执行的程序。这样的软件架构创新使得软件的开发与集成变得更 加灵活，尤其是当需要更新软件功能时，无需更新全部软件，只要更新特定的软件集群即可。 如图 2.1-6 软件集群技术示例中的蓝框所示，各个软件集群就像是控制器上的一块块拼图，而这些 拼图之间是通过软件集群连接块（Software Cluster Connection）拼接起来的。软件集群连接块由三部 分组成，分别是二进制清单（Binary Manifest），跨软件集群通信（Cross Cluster Communication）， 代理模块（Proxy Modules）。其中最关键的是二进制清单，它在编译阶段产生且 AUTOSAR CP 规定了 其标准格式，它为各个软件集群编译后文件（Binary Objects）之间提供了定义良好的接口，从而能将其 连接在一起形成完整的可执行文件。图 2.1-7 软件集群的连接展示了二进制清单连接两个软件簇的例子， 其中软件集群 A 运行时需要一个资源（Require Resource，指软件集群运行时所需要的一切，或是 S/R 接口，或是 NV 块），而这个资源正好可以由软件集群 B 提供（Provide Resource）。软件集群 A/B 的 二进制清单中都分别存储了这个资源的基本信息包括 ：资源属性（Require/Provide）、资源类型（S/R、 NV 块等）、资源 ID、句柄一览表（Handle，即用于访问该资源的信息如数据指针、函数指针、数据等）等。 AUTOSEMO 对于软件集群 A 来说，因为在其单独编译阶段没有相应的 Provide Resource，所以其二进制清单的句柄 一览表被默认值填写且是可修改的，如图 2.1-7 黄色框所示。对于软件集群 B 来说，因为其具备固定的 Provide Resource，所以其二进制清单的句柄一览表在编译时已确定且是不可修改的，如下图绿色框所示。 如果在烧写时进行软件集群连接，那么目标板内的软件集群连接器软件（On-board Software Cluster Connector）负责在烧写的同时，将软件集群 B 中资源的句柄拷贝至软件集群 A 中资源的句柄，从而完 成两个软件集群的连接。 图 2.1-7 软件集群的连接 013 

20 . 中国汽车基础软件发展白皮书 3.0 跨软件集群通信用于支撑 VFB 通信。而代理模块分为高代理模块（High Proxy Modules）和低代理 模块（Low Proxy Modules）两部分，其中高代理模块位于应用软件集群代替原先的基础软件模块提供 符合 AUTOSAR 标准的接口，低代理模块位于主软件集群负责实现真正的基础软件模块功能，二者之间 通过二进制清单连接。 2.1.4 典型应用案例 本章节将分享几个基于 AUTOSAR CP 基础协议栈的典型应用案例供读者参考。 1. SOME/IP 应用案例 在某公司 L3+ 自动驾驶项目中，整车和传感器通过 CAN 总线与自动驾驶域控制器的 MCU 进行交互， MCU 再将从 CAN 总线接收到的数据组包转发给 SOC 的各应用模块，MCU 与 SOC 之间则通过基于以太 网的 SOME/IP 通信协议进行交互。 常用的 SOME/IP 以太网消息类型有 ：REQUEST、REQUEST_NO_RETURN、NOTIFICATION、RE- SPONSE。其中 REQUEST 为期待响应的请求，客户端有需求时才会向服务端发送请求，且客户端会等 待服务端反馈的结果。例如，客户端如果需要向服务端请求 VIN 码，则可发送 REQUEST 类型的消息。 RESPONSE 则为响应消息，即服务端的用于响应客户端 REQUEST 类型的报文。例如 ：客户端向服务端 请求 VIN 码，服务端则通过 RESPONSE 类型的消息给客户端回复 VIN 码。REQUEST_NO_RETURN 为 不期待响应的请求，客户端有需求时才会向服务端发送请求，但客户端不关注结果。例如，客户端如果 需要向服务端请求打开车窗，客户端可发送 REQUEST_NO_RETURN 类型的消息。NOTIFICATION 为事 AUTOSEMO 件通知，客户端先向服务端订阅消息，服务端当发现被订阅的消息发生变化时则主动通知客户端。例如， 客户端向服务端订阅车速信息，服务端如果发现车速变化则可发送 NOTIFICATION 类型的消息给客户端。 在本案例中，由于 MCU 与 SOC 的通信数据具有数据量大、通信数据类型确定、数据周期性发送等特 点，因此 SOME/IP 消息采用 NOTIFICATION 类型。自动驾驶域控制器的软件架构如图 2.1-8 所示。 图 2.1-8 自动驾驶域控制器软件架构 014 

21 .中国汽车基础软件发展白皮书 3.0 MCU 一 侧 基 于 AUTOSAR CP 搭 建 应 用 软 件， 主 要 包 括 三 个 应 用 模 块 ：VDC（Vehicle Data Center）将整车相关 CAN 数据做预处理，此类 CAN 数据主要指 VCU、EPS、EPB 等控制器数据 ；XDC （X Sensor Data Center）将各传感器的 CAN 数据做预处理，此类 CAN 数据主要指毫米波雷达、组合导 航、智能摄像头等传感器数据 ；IDC（Internal Data Center）将预处理后的 CAN 数据转换成以太网数据 并通过 SOME/IP 协议发送到 SOC 一侧。SOC 一侧基于 AUTOSAR AP 搭建，其中 SDC（Service Date Center）将以太网数据转换为 SOC 应用模块所需要的数据。在 SOME/IP 通信中，SOC 侧的 SDC 作为 客户端，启动后即开始订阅 MCU 侧的所有已知服务，MCU 一侧收到订阅后即开始以固定周期向 SDC 侧 发送订阅的报文，为保证实时性，SOME/IP 的数据传输周期与 CAN 报文周期一致。 SOME/IP 序列化方式采用大端一字节对齐。因为一字节对齐是最简单的对齐方式，大多编译器很容 易实现 ；并且采用一字节对齐，序列化后没有冗余数据，报文的有效负载段都是有意义的数据，所以总 体传输效率得到了一定提升。另外，SOME/IP 通信报文中的 Payload 也会添加时间戳和 Rolling Counter 等信息，SOC 一侧的应用在使用 MCU 传来的数据之前，会先把时间戳取出来，并作数据校验、对齐、分 析等工作。SOME/IP 报文结构如图 2.1-9 所示。 AUTOSEMO 图 2.1-9 SOME/IP报文结构 本案例中的 SOME/IP 协议均基于 UDP 协议开发，它在用户有需求的时候才发送报文，这种方法有 以下几点优势： 一、传输效率高。与 CAN 等周期性的网络相比，总线上不会出现过多不必要的数据，从而减少了资 源消耗，点对点的全双工传输模式也让通信效率变得更高。 二、通信速率快。对于雷达这类较大的数据，需要 MCU 能在短时间内及时地将数据传输到 SOC，使 用以太网是目前各类总线通信中速率最快的，它最能满足大数据量的通信需求。 三、数据长度长。CAN-FD 报文数据长度最大 64 字节，LIN 报文数据长度最大 8 字节，单帧 Flex- ray 报文数据长度最大 254 字节，而基于 UDP 的以太网单帧报文长度可达 1500 字节，能满足大数据的 通信需求。 四、实现较简单。以太网已有成熟的 TCP/IP 协议栈，基于 Linux 平台还有开源的 Vsomeip 协议栈， 可直接移植使用。 2. 时间同步应用案例 在智能驾驶中，时间是一个非常重要的参数，各个系统中需要保证时间一致，其中包括车云系统之 间时间一致 ；域控之间时间一致 ；域控与各个 ECU 之间时间一致 ；ECU 与各个传感器之间时间一致等。 车云系统为保证时间一致，常在车载 ECU 中加装 GPS 模块，ECU 通过 GPS 数据与云平台时间保持一致。 车内系统（域控之间、域控与 ECU 之间、ECU 与传感器之间）为保证时间一致主要采用：PTP（Precision 015 

22 . 中国汽车基础软件发展白皮书 3.0 Time Protocol 高精度时间同步协议）、PPS（同步脉冲信号）、AUTOSAR CP 同步方案等。 如图 2.1-10 多传感器融合系统中，Camera ECU 通过高精度摄像头采集车道线、障碍物、标识等 信息 ；Radar ECU 通过毫米波雷达进行障碍物、障碍物速度等信息的采集 ；Camera/Radar ECU 通过 CAN-FD 将处理的数据交给 ADCU 进行数据融合，ADCU 中自带 GNSS 芯片保证与云端时间一致。由于 该系统对数据实时性、真实性要求比较高，所以需要保证 Camera/Radar ECU 采集的数据时间一致。为 了达到该目的，如图 2.1-11 时间同步步骤所示，本案例采用了 AUTOSAR CP 时间同步解决方案，即 ADCU 作为 Time Master 实体，Camera/Radar ECU 作为 Time Slave 实体，由 ADCU 对 Camera/Ra- dar ECU 进行时间同步。 图 2.1-10 多传感器融合系统 AUTOSEMO 图 2.1-11 时间同步步骤 时间同步的步骤与方法如下： 一、ADCU 以 1s 为周期发送同步帧，即图中 t1 时刻发送 t0 时刻的时间戳。 二、Camera/Radar ECU 在 t2 时刻收到同步帧后，记录 t2 时刻的时间戳。 三、ADCU 间隔固定时间（100ms）后发送跟随帧，发送内容即 Δt0 时间。 四、Camera/Radar ECU 在 t3 时刻接收到跟随帧后，进行绝对时间计算并将绝对时间更新到 ECU 中， 公式为：t3 = t0 +Δt0 + t3–t2。 注：本章有关 AUTOSAR 的内容是 AUTOSEMO 会员单位的经验解读，仅供行业参考。 016 

23 .中国汽车基础软件发展白皮书 3.0 2.2 AUTOSAR AP 2.2.1 技术形态 新四化（电动化，网联化，智能化，共享化）的变革驱使汽车软件系统变得更加灵活。汽车软件既 要安全又要可持续更新以反映新的功能特性或法规要求，为此需要新架构支持软件组件的动态部署以及 与非车载系统之间的交互。 今天的汽车 E/E 架构可划分为信息娱乐、底盘和车身控制等不同域，信息娱乐系统通常使用 Linux 或 商业化的通用操作系统，车身控制则使用标准的 AUTOSAR CP。随着未来新技术及深度嵌入式系统对计 算能力需求的不断增长，急需第三种控制器 —— 域控制器，用于集成特定领域的功能特性（如车辆动力域、 车身域等 )，形成域集中或跨域集中式电子电气架构。 在未来，随着汽车电子及软件功能的大幅增长，E/E 架构最终可能向基于中央计算平台的整车集中 式电子电气架构，以及车云协同控制发展。在这种趋势下，需要高度灵活、高性能且支持 HPC、动态通信 等特性的新软件架构平台 —— Adaptive Platform AUTOSAR 平台（下文简称 AUTOSAR AP）。 1. 软件分层架构 典型的域控软件架构如图 2.2-1 所示，整体可被分为四层，即操作系统层、基础平台层、原子服务层、 应用组合服务层。 AUTOSAR AP 在基础平台层，这一层包含了 AUTOSAR AP、AUTOSAR CP、专用基础功能等，主要 为整车提供基础运行环境。 AUTOSEMO 原子服务层是实现数据融合和控制逻辑的功能模块，作为服务的最小单位与单一执行实体，通过 API 为应用提供可按需编排的基础服务，实现一次开发多次复用，最大化提升开发效率。该层的设计目标是 原子服务与平台解耦，提升软件复用性。 应用层基于原子服务实现对整车服务、应用、体验等进行定义和组合增强，构建差异化竞争力的业务 应用，体现千车千面。 图 2.2-1 域控软件架构图 017 

24 . 中国汽车基础软件发展白皮书 3.0 图2.2-2 AUTOSAR AP在软件架构中的位置 AUTOSAR AP 在域控软件架构中位于中间件的位置， 通过服务和 API 为上层服务提供功能， 如图 2.2-2 所示。 AUTOSEMO 在 Non-AUTOSAR 环境中，系统已经实现了部分 AUTOSAR AP 标准组件，只需要实现剩余部分组 件即可满足 AUTOSAR AP 的标准。比如在 Android Automotive OS 中，软件框架提供了进程管理、执行 管理、Log、加密、生命周期管理等功能，基础软件供应商实现通信管理、诊断、升级、网络管理等功能， 即可满足 AUTOSAR AP 的标准。 2. 工具链 基于自适应平台的应用程序开发一般要经历三个阶段，分别是设计建模阶段、软件开发阶段、集成部 署阶段，为了更好地支撑这三个阶段的活动，AP 工具链具备以下能力： l 设 计建模阶段使用建模工具，用于生成 ARXML，完成 Adaptive Application、Service Instance、 Executable、Machine 等设计开发，配置 SWC（Software Component）相关配置项，完成 SWC 端口及框架设计 , 最终导出 AP 平台的 ARXML 文件。产品工具应具备支持导入导出、解析、编辑 ARXML 文件的能力。 l 软件开发阶段 ：使用 AP 产品生成工具，用于实现组件 API 代码及 Manifest 配置文件的生成。输 入是标准的 ARXML 文件，生成源代码和 Manifest 配置文件，另外需要包含应用层的代码编辑器 和代码库管理，实现源码编辑，编译链文件编写，代码库同步等功能。 l 集成部署阶段 ：使用集成编译调试以及部署工具，包含编译工具、可视化调试工具、部署工具、资 源监控等工具，支持编译、调试、部署等功能。 3. 开发方法论 为了支持 AP 平台下应用程序独立、敏捷、分布式的开发，需要在开发方法论上有一套标准化的方法。 AUTOSAR AP 开发方法论涉及工作产品的标准化，用于描述工作产品（如服务、应用程序、机器及其配 置）、工作产品应如何交互、以实现自适应平台产品开发过程中不同角色之间所需的信息交换。 图 2.2-3 简要展示了 AP 平台的开发工作流，总体来说需要经历三个阶段七个步骤，最终将开发的 018 

25 .中国汽车基础软件发展白皮书 3.0 软件集成入车辆中。 （1）架构设计阶段 ① 服务接口设计（Define Services）：主要是定义服务接口及数据类型，包括定义服务所包含的 method、event、field、trigger 等通信元素以及数据类型详细说明等； ② 机器配置设计（Configure Machine）：定义和配置机器的网络通信属性，包含网络连接配置，服 务发现配置等信息； （2）软件开发阶段 ③ 定义与配置可执行实例及通信方式，定义可执行实例如何访问软件集； ④ 定义软件集群所提供的服务实例、配置服务实例和可执行实例的映射； ⑤ 服务实例接口框架源码生成；软件集群源码开发及测试等； （3）集成与部署阶段 ⑥ 软件集群集成 (Integrate Software) ：配置可执行实例和进程的映射、定义和配置应用程序配置清 单、定义和配置服务实例部署信息； ⑦ ECU 集成 (ECU(Machine) Integrate)，定义应用程序执行清单 (Execution Manifest)、定义平台 程序的配置清单、诊断和进程之间的映射配置； AUTOSEMO 图2.2-3 AUTOSAR AP开发方法论 2.2.2 技术发展趋势 1. 架构发展趋势 （1）Adaptive AUTOSAR 的历史 Adaptive AUTOSAR 于 2017 年应运而生，主要为了提供高算力、高网络带宽下的基础软件开发平台 标准。目前最新版本为 R21-11。 019 

26 . 中国汽车基础软件发展白皮书 3.0 （2）Adaptive AUTOSAR 的发展趋势 ① 技术趋势 在 汽 车 行 业， 智 能 网 联、自 动 驾 驶、V2X、OTA 等 功 能 逐 渐 成 为 标 配，Adaptive AUTOSAR 面 向 POSIX 标准的操作系统，可以更好支持这些功能。在最新的标准中为了更好的支持开发，在可用性及稳 定性上做了如下提升： a. 可用性 ：提升模块特性的合理性及便利性。支持更多的 SOA 通讯协议、通信失效模式的检测、灵 活支持日志内容定义等。同时，针对域控制器的异构平台，新版本在 AP 与 CP 的共用特性及方法 论上进行统一，定义了自动驾驶的传感器接口、整车级健康管理的架构与接口、针对整车 OTA 升 级的流程等域控制器架构的使用功能等。 b. 稳定性 ：增加针对系统稳定的特性。如在 EM 细节中增加了配置进程错误码、功能组增加 unde- fined 状态、增加对进程意外终止的处理，PHM 中增加确定性执行的监控，UCM 中增加容错机制等。 同时在这些功能场景下，信息安全与功能安全成为不可或缺的关键机制。Adaptive AUTOSAR 针对 这两项安全需求，定义了完善的特性： a. 面向功能安全：新增了系统健康监控，主要用于系统协调健康状况 / 错误。主要包含以下内容： l SHM Client 交流平台健康状况； l SHM Master 确定健康指标； l 根据健康指标进行的机器恢复（例如降级）； AUTOSEMO l 增加了确定性同步的内容，描述了同步行为和周期性激活的要求，包括时间同步和数据同步。 b. 面向信息安全 ：增加了入侵检测系统管理，由标准化的接口来报告安全事件。通过标准化的过滤 机制来传输合格的安全事件。 l 增加了 Crypto API 的描述； l 软件和硬件解耦； l 支持分离式非耦合开发； l 应用程序独立于加密解决方案。 ② 基础软件技术路线 随着各种域控制器方案陆续问世，各细分赛道由分散到集中，由独立到整合。目前整车域控制器， 例如智驾域控，中央域控，智能座舱域控等均需得到高性能 MPU 芯片的支撑，因此 POSIX 标准系统的 搭载显得尤为必要。基于 POSIX 系统之上的 AUTOSAR Adaptive 平台及相关工具链，为应用开发过程中 的效率带来显著提高，而座舱域控一般在 Linux 基础之上搭载安卓系统，在程序启动、状态切换、存储等 方面有自己独立的生态，而诸如 SOA 通信、整车诊断、健康管理的方面需要参考 AUTOSAR AP 平台标准 给予补齐和增强，工具链未来需要从整车视角实施统一化配置。 ③ 新的分工趋势 受域控制器行业的蓬勃发展以及各项政策利好，越来越多的参与者以各种新的身份加入进来，整体 的行业角色将不再是 E/E 时代的 OEM、Tier1 及 Tier2 三种。随着产业链结构的变化，位于下游负责整 车生产和组装的主机厂（即行业所说的 OEM），将不再通过系统与设备集成来获取价值增量，而会转向 基于用户需求和自身产品定位，建立有效的梳理筛选机制，向上游 Tier1 及 Tier2 提出更多定制化的需求。 2. 工具链发展方向 工具链（tool chain）是在一套流程里面用到的所有工具和相关库组成的集合，上一个工具的输出或 020 

27 .中国汽车基础软件发展白皮书 3.0 环境状态成为下一个工具的输入或启动环境。因此，工具链的效率决定了整个系统的开发效率。所以随 着行业的发展成熟，工具链的发展将由现在分散的多工具相互切换配合形态，逐步升级到成熟开放的中 间服务体系，来匹配整个产业的发展态势，在平衡各自的专业分工的前提下避免产生信息数据孤岛。 现行的工具链标准基本是在 AUTOSAR AP 规范所约定的框架内按照给定的方法论实现功能，各家比 拼的是对 AP 服务模块的实现及理解。在第一阶段的服务实施提供后，要比拼的就是在整个产业上下游的 环节中的规范度、可移植性及整体的效率提升。 从集成角度，基于 AP 的开发工具链一般是基于 Linux 系统进行开发、编译和调试，在用户桌面端往 往出现多种开发工具同时使用的问题，因此亟需一套集成开发环境来简化用户桌面，为基于 AP 的应用开 发提供便捷性。 2.2.3 关键技术解读 1. 面向服务的架构（SOA） 当前整车电子电气架构，功能不集中，分散到不同 ECU，使得功能和信号交互异常复杂，代码和逻 辑冗余相当严重，而互联网开发思想不断涌入汽车行业，汽车电子电气开发也必须尽快适应变革。 面向服务的体系结构，是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务 之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，独立于实现服务的硬件平台、 操作系统和编程语言，使得构建在各种这类系统中的服务可以以一种统一和通用的方式进行交互。通过 引入 SOA 架构，不但可以使应用软件与硬件及应用软件与应用软件之间松耦合，还可以使车端软件、通信、 AUTOSEMO 信息安全能和云端环境产生很好的协同，实现一整套车云生态环境，因此车端采用基于服务的通信 SOA 是有效的落地方案。 2. 软硬分离 传统汽车控制器的开发模式是等硬件确定后，再进行软件的设计、开发、测试，软件的开发依赖于硬 件，无法先行或同步开发，导致软硬件两个团队人员只能顺序完成工作，浪费时间。并且一旦硬件发生改变， 软件则需要大量的修改适配，重复工作量巨大。在新型整车集中式 E/E 架构下，功能服务化，接口统一化， 增加了中间件层，软硬分离成为可能。 3. 虚拟化 当前高算力芯片层出不穷，通过虚拟化技术，将芯片上所跑的各类业务分类进行隔离已经是目前很 多车企的选择。同时，在软硬分离的背景下，在 x86 架构 PC 机上或云端通过虚拟化技术运行虚拟控制 器进行服务设计的验证也是目前的主流软件先行方案。 2.2.4 典型应用案例 1. 基于 AP 的基础软件产品和解析 （1）日志与调试 日志作为行为或状态详细描述的载体，提供可用于分析系统的活动和诊断问题的跟踪记录。在安全 事件分析、事件回溯和取证过程中起着相当重要的作用。 在 AP AUTOSAR 中，Log and Trace 模块负责管理和记录 AP 平台的日志，既可以应用于开发过程， 也可以适用于量产过程。在架构上，Log and Trace 模块会与 AP 的时间同步及通信管理等模块交互。基 于 AP AUTOSAR 标准定义的 LT 协议，Log and Trace 模块可以让 AP 应用程序将信息记录到通信总线、 控制台或文件系统上。同时 DLT 协议也提供了包括日志等级、日志 ID 等字段内容，日志客户端可以使用 此信息来关联、排序或过滤接收到的日志帧，便于日志的解析查看以及日志相关功能的扩展。 021 

28 . 中国汽车基础软件发展白皮书 3.0 平台典型的日志系统架构图如图 2.2-4 所示： 图2.2-4 Log And Trace案例 其中，App 通过使用 DLT 接口将相应的操作步骤、状态监控、故障信息等内容发送至 Daemon； Daemon 表示 DLT 守护进程，它接收并处理来自 AP 应用程序的日志信息，并根据配置对日志进行 终端显示、文件存储、网络传输等操作； AUTOSEMO Dlt-Viewer 表示通过网络传输接收 Daemon 日志信息的客户端，对日志信息进行 UI 展示，方便用户 进行日志的查看和分析。 （2）日志记录分析 上文介绍了从日志产生到日志数据流转的整个过程，基于已有的日志信息，Dlt-Viewer 可以提取出 我们所关注的数据，如图 2.2-5 所示。 Dlt-Viewer 提供相当多 DLT 日志处理功能，除了日志显示、日志导入 / 导出等功能外，还提供了强 大的日志过滤、标记等功能。过滤器可以是某一字段，甚至是正则表达式。它提供了插件的开发接口，极 大地提升了功能扩展的能力。 图2.2-5 日志记录分析 022 

29 .中国汽车基础软件发展白皮书 3.0 （3）系统启动监控 通过解析各功能模块产生的 DLT 日志，可以分析出整个系统上电启动过程，用户可以直观地观测各 功能模块的启动过程，并根据观测结果调整各功能的启动策略，达到功能模块稳定、快速启动的目的。 2. 基于 AP 的应用场景介绍 本节主要介绍基于 AP 的智能域控制器（后续简称 IDC）OTA 升级场景及其实现方案。IDC 的 OTA 功能可以进行自身应用软件及系统软件、关联器件固件的升级，并在数据管理、软件升级、可追溯性、安 全验证方面满足 AP 的相关要求。 在 OTA 的功能实现过程中， IDC 与外界的数据交互如图 2.2-6 所示。 云端 OTA 云服务器向车端 HUT （终 端信息展现单元 Head Unit & Telematics）推送升级任务，用户确认升级后，HUT 会通过网关向 IDC 及 其他 ECU 以 UDS 的形式发送升级指令及升级数据，IDC 接收升级指令与数据后，在确保安全的情况下 完成软件升级并向 HUT 反馈安装进度及安装结果。 云端 OTA服务器 4/5G/WiFi AUTOSEMO 车端 HUT GW ECU1 ... IDC 图2.2-6 IDC与外界数据交互图 （1）数据传输与管理 ① IDC 内部分为 OTA 进程和 UDS Server 进程，UDS Server 进程与 HUT 端交互，负责处理、转发 指令和接收软件包，OTA 进程处理软件包进行升级。 ② OTA 使用专用的磁盘分区保证有足够的资源来存储软件包及相关数据，从而保证数据的安全性。 ③ IDC 会进行完整性校验以保证软件包的完整性。 ④ OTA 结束后，IDC 会删除临时数据，最大限度节省空间。 （2）软件升级 ① OTA 采用双分区机制，通过活跃分区去升级备份分区，升级成功后重启备份分区，完成备份分区 和活跃分区的互相切换，轻松实现 IDC 上的应用软件、中间件、操作系统、配置数据的安装、更新、删除。 ② OTA 采用双分区机制，通过切换启动分区，可以实现 IDC 上所有软件及数据的快速回滚功能。 ③ OTA 支持周边器件的升级，如 MCU、相机等。 ④ OTA 内部维护状态机，状态变化实时落盘，可以支持在异常中断后恢复升级。 023