1、 1/136 智能网联汽车远程升级智能网联汽车远程升级（OTA）发展现状）发展现状及建议及建议 2/136 编写组成员编写组成员 中国汽车工程学会 中国智能网联汽车产业创新联盟 公维洁、陈桂华、纪蕴家、薛宇、刘正平、丁钰 国家市场监管总局缺陷产品管理中心 董红磊 国家智能网联汽车创新中心 鲍振标、刘兴亮、韩可强、李桂伟、张丽娜 华为技术有限公司 马涛 上海蔚来汽车有限公司 廖治、孔念智、金秀莲、王长胜 中国软件评测中心 邹博松、王卉捷 襄阳达安汽车检测中心 左少雄、李广军 国家工业信息安全发展研究中心 潘妍、张渊、余宇舟、孙娅苹 中国信息通信研究院 房骥、于润东 浙江长三角车联网安全技术有限公

2、司 胡昌国、王剑、范永霞 易图通科技（北京）有限公司 汤咏林、刘秋平 北京主线科技有限公司 王超、孙雁宇、王里 长安汽车重庆长安科技有限责任公司 刘俊 北京汽车研究总院有限公司 张文博 广州小鹏汽车科技有限公司 陈旭、张义 奇安信科技集团股份有限公司 许斯亮 博泰车联网科技（上海）股份有限公司 陈景、黄占威、唐焱 陕汽集团天行健车联网公司 冶少刚、田春荣 中国汽车技术研究中心有限公司 樊琛、朱永健 郑州信大捷安信息技术股份有限公司 刘为华 紫光展锐（上海）科技有限公司 周晓萌、朱勇旭 北京世辉律师事务所 刘晓霞 北京航迹科技有限公司 高红、王艳华 上海科络达云软件技术有限公司 聂晟 北京梆梆安

3、全科技有限公司 刘仟丰 浙江零跑科技股份有限公司 王伟 北京百度智行科技有限公司 王泰格 陕西重型汽车有限公司 罗鹏飞 中电科网络安全科技股份有限公司 王雍 一汽解放汽车有限公司 詹悦、李志宁、韩宝广 爱瑟福信息科技（上海）有限公司 彭维科 3/136 零束科技有限公司 王艺玮 兴唐通信科技有限公司 高暐暐 中电金信软件有限公司 袁巍 长沙行深智能科技有限公司 朱久艳、杨雄亮、刘桂武 中电车联信安科技有限公司 曹力文 西安深信科创信息技术有限公司 胡蓉 武汉光庭信息技术股份有限公司 万鹏 赛灵思电子科技（上海）有限公司 刘菲 中国汽车工程研究院股份有限公司 郭韬、王婧璇 沈阳美行科技股份有限公

4、司 高建宇 北汽福田汽车股份有限公司 李洪乐 4/136 目目 录录 第一章 前言.1 1.1 编制背景.5 1.2 编制方法.5 第二章 汽车远程升级（OTA)定义与技术体系.6 2.1 汽车 OTA 定义与应用场景.6 2.2 汽车 OTA 技术体系.10 第三章 汽车远程升级（OTA）政策法规标准研究.28 3.1 国内外政策法规发展现状分析.28 3.3 国内外标准发展现状分析.36 3.4 我国现有政策法规标准问题分析.44 3.5 构建 OTA 标准体系，支撑政府监管，赋能生态繁荣.46 第四章 汽车远程升级(OTA)产业生态研究.48 4.1 汽车 OTA 产业发展现状.48 4

5、.2 OTA 对汽车产业生态的影响分析.54 第五章 汽车远程升级（OTA）安全风险研究.62 5.1 OTA 安全形势分析.62 5.2 OTA 风险评估方法.63 5.3 OTA 网络安全风险分析.75 5.4 OTA 数据安全风险分析.77 5.5 OTA 功能安全风险分析.78 第六章 汽车远程升级(OTA)测试评价研究.80 6.1 国内主要第三方测试机构概述.80 6.2 OTA 标准合规测试.81 6.3 OTA 功能测试.82 6.4 OTA 安全测试.83 6.5 OTA 体验评价.99 第七章 汽车远程升级（OTA）发展建议.101 7.1 加强政策引导，完善监管机制.10

6、1 7.2 强化标准引领，规范行业发展.102 7.3 重视流程管理，形成完善体系.103 7.4 推进协同创新，构建良好生态.103 参考文献.105 附件 1:UN R156 与 ISO 24089:2023 的映射关系20.107 附件 2:2021 年-2022 年 OTA 召回情况分析.112 附件 3:OTA 企业开发案例.118 附件 4:OTA 系统功能测试主要测试项.125 附件 5:OTA 体验评价主要测试项.132 5/136 第一章 前言 1.1 编制背景 随着汽车产业电动化、智能化、网联化、共享化加快融合发展，汽车电子电器架构不断演进，汽车软件架构向面向服务的架构（S

7、OA）转型升级。汽车 SOA架构为远程升级（OTA）技术上车应用提供了基础，OTA 技术的广泛应用也推进了软件定义汽车的进程。目前，OTA 技术逐渐成为车企快速迭代产品功能、优化产品性能、为用户提供增值服务提升体验，以及产品召回的手段。多个政府部门发布了 OTA 相关政策及管理指南，以建立车辆安全防护措施，明确企业安全主体责任，并切实保障消费者合法权益和社会公共安全。然而汽车 OTA 技术发展将带来安全风险边界不断扩展的问题，同时 OTA 技术受标准化程度、电子电器架构发展进程、汽车软件开发能力、产业协同度、数据积累程度等因素影响，还不能发挥出降本增效、高效敏捷开发的最大潜力。本研究从既保障安

8、全、又鼓励 OTA 技术应用的目标出发，开展 OTA 定义与技术体系、政策法规标准现状、产业生态现状、安全风险与测试评价等相关研究，并分析提出发展建议，以支撑相关政策法规标准制修订和企业软硬件及 OTA技术研发，力求为智能网联汽车产业发展营造良好环境。1.2 编制方法 本研究采用联合研究方式，依托中国智能网联汽车产业创新联盟（以下简称联盟）电子电气信息架构与网络工作组、信息安全工作组，联合行业相关单位开展 OTA 发展现状及应对研究。调研政府机构、车企、服务供应商、第三方检测认证机构相关进展和面临问题；各章节确定 12 家牵头单位组建小组编制；组织行业会议，邀请专家评审。6/136 第二章 汽

9、车远程升级（OTA)定义与技术体系 OTA 技术最早应用在 PC 电脑和移动手机行业，近几年才开始在汽车行业中广泛应用。然而车内通讯网络的复杂性、汽车电子系统的碎片化等因素限制着OTA 技术整车范围普及。本章从 OTA 定义与应用场景、OTA 实现流程和“云-管-端”关键技术进行研究，为行业从业者对 OTA 技术的设计开发、技术验证和生产工作提供参考。2.1 汽车 OTA 定义与应用场景 2.1.1 OTA 定义及分类 OTA 是 Over the Air 的缩写，通常指的是远程无线方式，OTA 技术可以理解为一种远程无线升级技术。在无特别说明情况下，本文所指的 OTA 是所有汽车远程升级的统

10、称。实现 OTA 的基础是车辆具备远程联网功能，这意味着正是智能网联汽车渗透率的快速增长，推动了 OTA 的快速普及。OTA 的本质是通过技术实现软件更新，智能网联汽车与传统汽车的软件升级不同之处在于，通过 OTA 技术，原始设备制造商（OEM）可以不用通过售后服务中心，而是直接远程连接目标联网车辆，将软件更新推动至待升级的车辆。随着 OTA 的应用越来越广泛，针对升级对象的不同，延伸出来很多不同的概念。人们在谈及 OTA 相关业务时通常会在前面增加一个具体对象，用于表明使用 OTA 技术实现何种功能，比如远程软件升级、远程固件升级、远程配置、远程数据更新等。然而在一些 OTA 解决方案中，已

11、经模糊了不同类型远程升级的边界，将所有可升级的软件对象抽象为软件簇，而软件簇包含了从小到配置字信息大到整个操作系统固件所有颗粒度的对象。并且，GB汽车软件升级通用技术要求中对软件升级（Software Update）的定义已经涵盖了下述几种 OTA 概念（远程诊断除外）。2.1.1.1 远程软件升级(SOTA)SOTA（Software Over-The-Air），即远程软件升级，是指在操作系统的基础 7/136 上对应用程序进行远程升级。SOTA 通过远程下载并给车辆安装“应用程序升级包”，来实现控制器功能的一个“增量”更新，一般应用于娱乐系统和智驾系统。SOTA 一般涉及应用层小范围的功能

12、局部更新，不包括汽车核心系统，对整车性能和安全影响较小，升级前置条件要求较低。SOTA 的增量更新策略，可以大幅减小升级包文件大小、从而节约网络流量和存储空间。2.1.1.2 远程固件升级(FOTA)FOTA（Firmware Over-The-Air），即远程固件升级，是指囊括车辆底层算法至顶层应用的综合升级，在不改变车辆原有配件的前提下，通过远程下载并写入新的固件程序进行设备升级。FOTA 包括驱动、系统、功能、应用等的升级，与硬件的更换没有关系。FOTA 涉及车辆的核心系统，包括但不限于汽车动力控制系统、底盘电子系统、自动驾驶系统、车身控制系统等核心零部件的控制系统，可以改变车辆的充放电

13、、动能回收、加速性能、辅助驾驶系统逻辑等与深度驾控有关的体验。理论上所有支持固件更新的电子控制单元（ECU）都可以涵盖在 FOTA 范围中。2.1.1.3 远程配置(COTA)COTA（Configuration Over-The-Air），即远程配置，是指通过 OTA 的方式实现远程修改配置字，以达到修改软件功能配置的目的。配置字是一组以数据标识码(DID)方式存储在 ECU 上的数据，可通过诊断指令进行读取和修改。它根据特定的编码规则与车辆功能特征码一一对应，通过配置可判断车辆的功能配置，软件可根据配置实现相应的功能。远程配置常见的应用场景是远程开启和关闭某项功能，例如软件订阅功能。2.1

14、.1.4 远程诊断/远程数据更新(DOTA)DOTA 有两种常见解释：DOTA(Data Over-The-Air)，即远程数据更新，是指一些独立于软件程序存在的数据包的更新，比如，地图数据、语音数据和算法模型数据等。这类更新的特 8/136 点是数据量比较大，更新流程相对独立，比如，地图数据通常由地图应用自行更新，而数据量也可能高达几 G 到几十 G。DOTA(Diagnostic Over-The-Air)，即远程诊断，通过云平台实时数据采集监控，主动性地检查汽车系统异常问题，为远程问题修复与人工问题修复提供决策依据。远程诊断的触发方式有两种，一种是用户在车辆上发现异常状况的响应式；另一种

15、是周期性收集通讯网络、应用程序、硬件效能、使用操作记录、系统程序等状态信息，利用大数据后台分析监测故障。2.1.1.5 其他类型(XOTA)随着汽车智能化程度越来越高，除了车辆本身软件的升级外，还可能会涉及到外部智能设备交互功能的软件更新，比如，智能钥匙、AR 设备等。目前有些企业和组织将所有与车辆相关联的软件升级统称为 XOTA，即 Everything Over-The-Air 的意思。2.1.2 OTA 应用场景 2.1.2.1 车辆生命周期维度 从开发者编译生产出目标版本软件，到该软件更新至目标硬件设备上的全过程涉及多个阶段。在不同的阶段，受产品形态和生产环境限制，所适用的软件更新目的

16、和手段也有所不同，如下表 2-1 所示。目前，大部分车企的 OTA 主要集中在售后软件更新，但不论是从效率上还是成本上 OTA 都体现出了巨大的优势。随着 OTA 应用越来越成熟，从单一的售后升级场景向更多的应用场景发展是的必然趋势。表表 2-1 车辆生命周期维度的软件更新应用车辆生命周期维度的软件更新应用 车辆生命周期车辆生命周期 软件更新目的及手段软件更新目的及手段 零部件阶段 ECU 供应商产线是最早可以切换到最新软件版本的节点，该节点进行软件切换可避免旧版本软件继续生产从而流向下游，称为供应商产线断点。由于该阶段还是零件状态，通常只能通过芯片烧录工具或者供应商特定的工具进行软件更新，不

17、适用 OTA 方式。总装阶段 由于零件需提前订购，仍有一定量的零部件在供应商产线断点前流转到 OEM 库存，总装 9/136 线的电检工位可以完成部分软件的刷写，称之为 EOL(End of Line)软件刷写。然而 EOL 软件刷写会影响产线节拍，导致 OEM 不会在产线进行大量软件刷写。总装完成时车辆已经具备 OTA 的条件，如果通过 OTA 方式进行产线刷写，可实现多车并线刷写且不受产线工位影响，将极大提高产线软件灌装的效率。目前，已经有个别企业实现总装阶段 OTA。驳运阶段 车辆从总装线下线到经销商库存要经过一定的驳运过程。对于体量大且紧急程度不高的软件，在总装线灌装会影响效率，如果利

18、用驳运过程进行软件更新，能降低对产线节拍的影响。OTA 使得利用驳运过程更新软件成为一种可能，但在驳运过程中更新对电源供应管理及车辆安全是否有影响需要更深一步考虑。售前库存 经销商通常有一定的库存车辆，在正式销售前库存车辆可能需要对软件版本进行升级。以往是在进行最终售前检查时，将软件更新到最新版本，存在更新时间长，影响用户交付体验等问题。OTA 技术可将库存车辆自动同步至最新版本，大大减少在交付过程中软件更新的耗时，提升效率。售后阶段 过去的售后阶段软件更新，用户需要将车驾驶到指定维修站完成更新。通过 OTA 技术，用户可随时随地通过简单操作完成软件更新，使车辆“常用常新”。目前已成为汽车企业

19、增加用户粘度和解决软件售后问题及构建生态服务体系的一个重要手段。2.1.2.2 软件运营管理维度 从软件运营管理的维度 OTA 的典型应用场景如下表 2-2 所示。表表 2-2 软件运营管理维度的软件更新软件运营管理维度的软件更新典型典型应用场景应用场景 典型应用场典型应用场景景 应用场景描述应用场景描述 软件召回 软件引起重大功能缺陷时，例如存在功能安全、网络安全/数据安全重大风险、法规相关问题，通过 OTA 方式召回，可以在短时间内批量完成问题软件的修复，尽可能降低软件缺陷造成的影响，效率高且成本低。问题修复 对于一些非严重性问题，通过 OTA 方式，可以周期性推送软件版本，进行问题修复。

20、性能优化 与缺陷修复类似，OTA 方式的便捷性，使得性能优化类的软件更新也逐渐得以重视，目前已经是常见的 OTA 场景之一。软件个性化定制 此应用场景通常为 COTA 应用，比如用户可根据个人需求，完成怠速调整、车下启动/熄火，自动启停等参数的设置更新。新功能交付 OTA 使得售后软件功能持续迭代成为可能。通过 OTA 可新增功能的多少，已成为用户评价OEM 的对重要指标之一。10/136 付费功能订阅 功能订阅是新功能交付应用场景衍生出来的一种新的行业形态。车企在售卖车辆之后，针对部分新增软件功能以付费方式供用户购买使用。这使得车企除了车辆销售之外，有了新的盈利可能性，这也是目前汽车企业非常

21、乐于探索的一种 OTA 应用场景。2.2 汽车 OTA 技术体系 2.2.1 OTA 实现流程 汽车软件更新的本质是将供应商或者 OEM 内部开发部门编译出来的软件或者数据替换当前车辆 ECU 中的版本，以实现预期的特定功能。因此，汽车软件升级所需要的核心工作是建立远程传输链路并实现OEM云端系统远程更新车辆ECU 中的软件数据。同时，为了准确、安全、可靠地完成 ECU 软件的更新，OTA系统需要云端管理系统对软件、升级对象进行管理，以实现人工操作到自动化的转变；车端系统需要完成软件数据的接收和分发工作，并保证无专业技师操作情况下的安全升级。图 2-1：OTA 实现流程(来源 AutoSAR)

22、图 2-1 是一个典型的 OTA 系统框架，包含了三个基本要素，即云端的 OTA平台、车端 OTA 主控、OTA 对象。其中：OTA 云平台负责 OTA 升级包管理、车辆管理及 OTA 发布等功能，车端 OTA 主控负责从 OTA 云平台下载升级包并将其刷写到目标 ECU，OTA 升级对象即最终软件刷写的主体，从主控接收软件 11/136 并完成自身软件更新。OTA 的基本实现流程（图 2-1）可归纳为下表 2-3 所示步骤。表表 2-3 OTA 的基本实现流程的基本实现流程 步骤步骤 内容内容 1.升级包制作 ECU 供应商或车企内部开发团队完成软件开发并编译产生新版本的软件，通过约定的方式

23、制作成升级包。2.上传软件 供应商或 OEM 内部开发部门生产的软件验证合格后，经由产品生命周期管理系统(PLM)或类似的系统流转到 OTA 云平台，供更新使用。3.OTA 任务发布 发布过程是选定特定软件，通知至指定目标车辆，通常由 OTA 运营人员完成。发布之后的软件通常经过一系列安全处理后传至专门的文件服务端供车辆下载。4.下载升级包 OTA 发布完成后，通常 OTA 云平台需要通知车端 OTA 主控执行软件更新动作，OTA 主控根据与云平台命令交互获取信息，从指定文件服务端地址下载所需要的升级包；不同的OTA 系统可能由于升级对象升级包大小原因，OTA 主控不会直接下载升级包而是通过相

24、关命令控制目标 ECU 完成其所需升级包的下载。5.安装 安装过程是由 OTA 主控根据约定的协议，将目标升级软件刷写到对应 ECU 指定存储介质。ECU 硬件不同、通信方式不同，通常安装的过程会有所差异。6.校验 软件安装前后需要进行完整性校验及真实性校验。完整性校验保证安装过程传输的数据没有被篡改，真实性校验保证所安装软件没有被仿冒伪造。7.激活 根据 ECU 结构不同，安装步骤可能还会包含激活操作，即双备份分区 ECU 更新完成后进行分区切换。此外，OTA 主控除了处理控制安装过程外，还需要控制车辆的状态，保证升级过程车辆的安全。8.回滚 针对升级异常的情况，将软件版本恢复到升级前版本的

25、过程，主要目的在于保证升级失败ECU 功能仍可用。9.状态上报 OTA 主控需要将升级状态同步到 OTA 云平台，保证 OTA 云平台可以根据车辆最新状态编排升级任务。同时，可根据业务实际情况，同步更新过程中各阶段状态至 OTA 云平台，以便更精准地控制升级。2.2.2 OTA 云平台架构及关键技术 OTA 云平台是支撑 OTA 业务正常运行的相关云端系统的集合，既包括实现OTA 核心功能的 OTA 服务端，也包括了其他关联系统如企业 IT 管理系统、安全服务端、web 控制台以及文件服务端。OTA 云平台业务范围涉及软硬件生命周 12/136 期管理、业务流程整合、软件远程分发等软件更新所有

26、相关业务，是一个软件升级管理体系(SUMS)。2.2.2.1 云平台架构 基于 OTA 产品业务形态，结合系统组件之间松耦合高内聚的标准，行业内普遍将云平台设计为 4 层的分层架构型式，如图 2-2 所示，包括前端展示层、路由网关层、业务服务层和数据存储层。前端展示层是系统与用户交互的 web 应用层，用户访问和操作云平台系统的交互接口；网关路由层包括指令控制层和网关接入层，是云平台与车端建立通信链接以及控制车端流程的通信中间件；业务服务层负责所有 OTA 相关业务逻辑的处理，包括车辆、软件包管理、策略管理等诸多业务模块，是 OTA 云平台的核心；数据存储层负责 OTA 所有业务相关数据存储，

27、包括基本的数据库集群数据缓存和大文件存储等。图 2-2 OTA 云服务框架图（1）前端展示层前端展示层 前端展示层的划分，是基于前后端分离开发方式设计的架构分层模式，主要负责 Web 端用户交互页面的功能。核心思想是前端页面通过调用后端的接口并进行交互，前端专注于交互页面的开发，业务逻辑由后端负责。对 OTA 云平台而言，前端展示层可以理解为业务服务层的用户交互接口，其展示功能与具体业务功能一一对应。（2）指令控制层指令控制层 13/136 各业务平台与网关接入层的连通介质，接收来自业务系统指令并将指令发送至网关可访问的缓存中，接收来自网关回写的升级状态至各业务系统可访问的消息队列中。（3）网

28、关接入层网关接入层 针对不同的数据格式及上层需求，接收封装来自车载终端传输的数据，并流向缓存、消息队列等中间件。（4）业务服务层）业务服务层 业务服务层是 OTA 服务所有业务及相关流程管理功能在云平台端的实现，除了车辆管理服务、软件包服务、版本服务、策略管理和任务管理 5 个支撑 OTA的核心功能外，还包括关联系统审批、数据对接、信息安全服务、测试、统计分析、日志查询等重要辅助功能。由于不同的企业内部管理存在差异，云平台所支持的辅助业务可能存在较大差异，常见服务列举见表 2-4。表表 2-4 常见服务举例常见服务举例 常见服务常见服务 业务内容业务内容 车辆管理服务 维护所有可升级车辆的信息

29、，包括品牌、车型、配置以及每个单车所包含的可升级设备信息等。软件包服务 用于控制器升级包的在线管理、差分包的制作及管理，相当于 OTA 的仓库管理，需要维护不同车型所有 ECU 不同版本的所有软件实体，包含软件包的签名加密以及各版本与其关联关系等。版本服务 包括基线版本管理、软硬件版本及版本号管理，每个软硬件版本的依赖条件管理，并维护每一个软件版本所适用的品牌、车型、配置等。策略管理服务 需适配各种复杂软件更新，提供灵活的设备群组管理、下发条件配置，支持升级任务策略配置，满足各类升级需求。任务管理服务 对升级推送任务的管理，每次选择特定版本的软件包向指定车辆推送即可视为一个任务。任务管理包含：

30、1）任务条件设定，如任务所适用的车型、升级模式、升级策略、任务有效时间；2）发布车辆选择，指定将该任务适用于哪些车辆，可加入黑白名单，批量导入汽车唯一识别码(VIN 码)、标签匹配等业务逻辑；3）任务的基本操作，如创建、暂停、取消等。审批服务 功能在于把传统的线下软件发布的审批流程通过 OTA 平台实现在线化，达到自动流传，提高效率的作用。14/136 数据对接服务 数据对接的系统包括 PLM、MES、EOL、DMS、ADS，数据对接涉及到软件版本信息获取、车辆信息初始化、用户信息、售后信息同步等。信息安全服务 用于保证 OTA 的安全，主要通过与 PKI 系统对接完成升级包的签名加密，车端设

31、备的身份认证，通信链路的认证和加密。安全访问控制服务 通过云平台端的安全访问控制服务在线化管理会话控制的安全算法，防止未授权的系统或者设备对车辆 ECU 进行软件更新，更利于对每个 ECU 实现独立的安全访问方案。测试服务 用于支持 OTA 的测试，主要包括 OTA 升级策略、升级配置信息和任务等，以保证升级效果符合期望目标。统计分析服务 用于动态统计 OTA 升级状态，可以通过可视化展示升级状态，快速了解升级任务进度。同时，可以根据统计分析结果动态调整 OTA 任务推送的车辆数，保证系统资源和售后资源得到最有利的分配。日志查询服务 包含云端日志、车云交互日志以及车端远程日志等查询功能。基础信

32、息服务 主要针对 OTA 云平台本身的信息管理，如账号权限管理等。（5）PKI 系统系统 公钥基础设施（Public Key Infrastructure，PKI）：基于公钥密码体制实现数字证书的发布、撤销和管理等功能，并为数字证书用户提供相应服务的系统。其目的在于创造、管理、分配、使用、存储以及撤销数字证书，可以用来保证通信对象的身份真实性、软件程序的来源真实性和完整性、通信行为的不可否认性等。PKI 在 OTA 系统中的作用主要在于为相关实体发放数字证书，通过密码技术保证升级包和升级过程的安全。主要包括车辆证书、设备证书、供应商证书等的申请和校验；云端对车端身份认证，车端对云端身份认证；升

33、级包的安全认证等。（6）外部数据系统）外部数据系统 外部数据对接的系统可能包括整车生命周期配置系统（VLCS）、远程诊断系统、软件可售系统及一些其他支撑系统组成。主机厂研发部门需要根据车型的功能规划确定该车型所对应的软硬件相关配置。需要进行软件更新时，从 VLCS 系统中确定所涉及的车型和影响的功能范围，并依据确定好的范围，从物料信息管理系统(BOM)中申请软件物料号作为版本控制依据，供应商软件释放后经由产品 15/136 生命周期管理系统（PLM）系统通过验证审批后流转到 OTA 服务端供升级使用使用。OTA 服务端管理设备中初始的车辆信息，可通过对接 MES 在车辆下线检验合格后将新生产车

34、辆自动注册到 OTA 云平台，所有升级目标车辆应保证是已注册车辆。除此之外，根据实际需要还可能会从汽车经销商管理系统（DMS）系统获取经销商及售后服务站点信息，售后系统通常也需要与 OTA 系统关联以同步最新版本信息以及线下配置更改信息等。另外，OTA 系统在升级前可通过远程诊断系统获得最新的 ECU 配置信息及状态信息，并且当远程诊断系统发现问题后，可以通过 OTA 系统下发经过测试验证的补丁包来修复。对于一些有运营需求的主机厂来说，通过 OTA 系统配合软件可售系统，可以实现软件付费升级、功能付费使用等后向运营，真正实现“千车千面”、“用户定义汽车”。（7）数据数据存储层存储层 数据存储层

35、包括数据库集群、缓存和存储节点，分别用于存储 OTA 云平台不同类型的数据。其中，数据库集群，主要用于存储车辆信息版本信息等关系型数据；缓存，为了解决数据库性能瓶颈问题，可以通过多架设一层缓存层来减少对数据库的直接访问；存储节点，针对较大的升级包、配置文件等需要提供车端下载的文件，通常可以存储在分布式存储节点上。2.2.2.2 关键技术（1）安全技术）安全技术 OTA 服务端以及企业 IT 管理系统、安全服务端、web 控制台、文件服务端等关联系统，会面临传统云平台的所有安全威胁。为保证 OTA 升级的安全性，常用安全技术如表 2-5 所示。表表 2-5 OTA 云平台常用安全技术云平台常用安

36、全技术 名称名称 技术要点技术要点 PKI 签名验签技术 在升级过程中，OTA 系统采用数字证书签名方案，终端从 OTA 云平台下载的升级包、升级脚本均经过签名处理，升级前需验签正确后才进行升级。16/136 安全访问控制 通过云平台端的安全访问控制服务，OTA 车载系统采用网关内置或终端内置的安全访问函数方式实现校验方案，只有全访问验证通过，ECU 才会执行后续对应安全访问等级要求的请求。数字证书身份认证及信息安全 PKI 数字证书用于实现车辆身份管理，车、云身份认证；用于 OTA 云平台与车端上下行消息的加解密、签名、验签。数据安全 通过在组织中建立数据安全管理体系、建设云平台数据全生命周

37、期的主动安全防护和数据安全运营能力，保护数据安全。（2）OTA 技术技术 OTA 系统常用升级技术如表 2-6 所示。表表 2-6 OTA 云平台常用升级技术云平台常用升级技术 OTA 技术技术 技术要点技术要点 升级包管理 用于控制器升级包的在线管理、差分包的制作及管理。脚本管理 用于控制器升级执行脚本文件的在线管理。升级策略管理 用于升级任务执行条件（目标版本对目标车辆、整车状态、控制器状态、时间、信号等影响因素的依赖关系）的在线管理。升级效率管理 制定相关策略提升升级效率，降低升级失败次数。并通过日志分析其原因，进行技术迭代开发。2.2.3 OTA 车载端架构及关键技术 2.2.3.1

38、车载端架构 OTA 车载端功能模块主要包括 2 大部分，即 OTA 主控和 OTA 对象，如图2-3 所示。OTA 主控是车端 OTA 系统的核心，车端所有 OTA 业务逻辑均由主控实现，包括上报车辆信息、下载更新文件、升级包安装、车辆状态管理、人机交互等。17/136 图图 2-3 车载端功能模块车载端功能模块(参考参考 AutoSAR UCM)（1）OTA 主控功能模块主控功能模块 按照车载端的工作流程，车载端的功能模块包括：OTA 客户端负责与云端进行数据交互；下载模块负责升级包下载及分发；升级管理模块负责升级过程的控制；升级代理负责执行软件刷写或者软件安装；人机交互模块负责升级信息提示

39、、用户输入、升级过程的展示等，如表 2-7 所示。表表 2-7 OTA 主控功能模块主控功能模块 功能模块功能模块 功能描述功能描述 升 级 管 理（OTA Manager）作为 OTA 的核心，管理车辆所有 ECU 的更新过程，控制着将固件更新分发到 ECU，并告知 ECU 何时执行更新，这在多个 ECUs 需要同时更新的情况下尤为重要。OTA 任务下发到车辆后，OTA Manager 需要判断车辆条件，对于不符合条件的车辆，需要中止升级任务并上报给云平台，安全完成软件升级后，也要上报云端。若想实现单车定制化功能，OTA Manager 还需能够灵活定义升级的具体范围，升级时机，升级内容，提

40、示事项，失败后给用户的失败处理提示等。OTA 客户端 负责 OTA 主控与 OTA 云平台交互，包括下发 OTA 云平台的 OTA 控制命令，反馈控制命令的执行结果，发起更新检查请求，同步升级过程状态等。下载管理模块 负责从文件服务端下载升级所需升级包和文件，支持断点续传，保证升级包可以分多次下载，同时也避免部分重复下载造成流量浪费。18/136 安装模块 负责将升级包安装到对应的 ECU。不同的 ECU 类型会需要不同的安装模块，比如 FBL安装模块用于仅支持 Bootloader 升级 ECU，AB 安装模块用于支持 AB swap 双备份分区升级方式的 ECU,其他安装模块主要是指一些采

41、用私有协议进行升级的智能 ECU 车辆状态管理 负责确保车辆在安全状态下进行升级，其功能主要包括两个:车辆状态判断，通过预设条件判断判断车辆状态是否满足 OTA 的要求，比如判断车辆的电池电量是否足以支持完成升级、车辆是否处于非行驶状态等，这些条件通常是通过监控车辆相关的信号实现；车辆状态控制,通过特定的控制命令或者信号值，限制车辆非升级必须的功能，保证升级过程车辆状态不可被改变，从而维持在安全状态。人机交互接口 人机交互接口是 OTA 主控通过相关显示设备与用户进行交互的操作接口，控制 OTA相关信息在车内的娱乐主机显示屏或者手机 APP 等设备上的显示。（2）OTA 主控部署方案主控部署方

42、案 由于车辆 E/E 架构的不同以及控制器升级方式的不同，功能模块的部署方式也有所不同。在传统网关分布式架构下，按照 OTA 主控部署的位置不同，大致分为：远程信息处理控制单元（TCU/T-BOX）方案、车载信息娱乐系统（IVI）方案、网关（GW）方案，如图 2-4 所示。前两种方案，由 TCU/IVI 来进行 ECU的软件刷写，GW 仅作为路由实现数据的转发，刷写的链路比较长；后一种方案直接是由 GW 进行刷写，刷写链路较短，但是 GW 并不能直接联网，如果通过TCU/IVI 路由联网必须增加安全机制，或者由 TCU/IVI 下载升级包后再分发至网关。图图 2-4 传统的传统的 OTA 主控

43、部署方案主控部署方案1 传统网关分布式架构下，由于控制器分散以及层级很深，导致在实现 OTA的过程中要进行多次的转发和透传，容易导致数据丢失，增加升级失败的概率。另外，需要在 OTA 主控内部对软件进行备份，以保证升级失败后，控制器可以被回滚。由于传统控制器的芯片 Flash 和 RAM 容量小，实现也比较困难。19/136 对高算力和大带宽数据传输的迫切需求和“软件定义汽车”的理念驱动，各家车企逐步开始进行整车 E/E 架构的升级和变革，引入了“中央计算平台+区域控制器”的中央集中式架构，整体 E/E 架构更加扁平化，有利于实现整车级的 OTA。中央控制器和域控制器之间采用的是以太网，数据传

44、输能力增强；并且 SOA 架构使得域控制器之间的交互机制更加灵活。针对区域控制器的 OTA 主控部署方案如图 2-5 所示。可采用中央控制单元(CCU)作为升级主控，对于 ECU 的刷写有两种方式：1)区域控制器作为网关路由 UDS 报文，主控通过 UDS 升级区域控制器和该区域的所有传感器和执行器；2)区域控制器作为副主控，即升级主控先将该区域所有 ECU 的更新文件传输到区域控制中，由区域控器完整自身升级以及与其连接的执行器和传感器的刷写1。图图 2-5 区域控制器方案区域控制器方案（3）ECU 端架构方案端架构方案 车端 ECU 作为被升级对象，在 OTA 系统中主要功能是按照一定的协议

45、升级主控接收目标版本数据，将目标版本数据写入都指定的存储区域中并引导运行新版本软件，从而实现自身软件的更新。按 ECU 芯片类型及运行软件的特性可分为普通 ECU 和智能 ECU，而不同的 ECU 类型根据其内存空间结构又可以分为单分区和双分区两类。针对两类 ECU 的两种不同分区方案，ECU 端的升级可以大致归类为 4 种方案，本小节将分别对其展开讨论。普通 ECU 单分区（Bootloader）升级方案 普通 ECU 由于存储空间有限，通常会采用流式刷写的方式进行升级，所谓流式刷写即先将目标刷写空间的数据擦除，然后传输数据的同时，ECU 将已接 20/136 收的数据写入目的存储地址，通过

46、这种方式可以省去存储升级包的内存空间。传统的 BootLoader 通过 UDS 协议刷写的方式就是典型的流式刷写。如图 2-6 所示，普通 ECU 单分区结构只有 BootLoader(启动引导程序)和应用程序分区。该类型 ECU 需要更新时，首先将 ECU 从当前运行的应用程序分区切换至 BootLoader 运行，在 BootLoader 中将应用分区当前版本数据擦除后，再从升级主控接收新版本数据并写入应用程序分区，数据检验无误后重启 ECU 切换至应用分区即可运行新版本软件。图图 2-6 Bootloader 升级方案示意图升级方案示意图 这种方案缺陷非常明显，由于只有一个应用分区，升

47、级前需要擦除，导致升级过程 ECU 功能无法使用，如果更新过程异常中断或者失败也会导致功能无法使用。另外，这类升级通常需要在车辆非运行状态下才能进行，在软件数量较大所需升级时间较长的情况下，对车辆低压电池供电，尤其对于燃油车挑战较大。由于这用方案具有对内存空间要求低、在 BootLoader 进行更新不受应用程序干扰、实现简单等优势，目前现有升级解决方案中大部分普通 ECU 的更新仍采用这种方式。普通 ECU 双分区（AB 分区）升级方案 通过 AB 分区方案，为软件的运行版本和升级的目标版本分配不同的存储区，A 与 B 分区彼此为回滚，A 分区系统运作提供服务时，刷新 B 分区，待 B 分区

48、软件刷写完成通过校验后，下次重启时载入 B 分区；若刷写错误或关联 ECU 刷新失败，则仍以 A 分区系统启动，从而提高升级的可靠性，最小化回滚所需的时间。对于 AB 升级，其实有三种实现方案：第 1 类基于硬件辅助的 A/B 交换方案。该方案要求 ECU 内存足够，而且支持地址重映射，也就是当新版本软件刷写完成，通过更新映射地址来激活新版本软件，即新版本软件运行的入出地址不 21/136 变；第 2 类与第 1 类的差别在于 ECU 硬件不支持地址重映射，激活新版本软件的入出地址会变化；第 3 类，基于外扩内存的 A/B 交换方案，该方案是需要额外的外扩内存，备份当前版本软件和旧版本软件，新

49、版本软件会先刷写原先的旧版本软件空间，然后擦除 ECU 内存的当前版本软件，刷写新版本软件，完成激活。AB 升级方案示意图如图 2-7 所示。图图 2-7 AB 升级方案示意图升级方案示意图 智能 ECU 单分区升级方案 智能 ECU 是指具有高性能处理器，可运行现代操作系统(如 Linux、QNX、Android 等)支持文件系统的控制器。这类控制器存储介质成本相对较低，一般存储空间较为充足，通常不会采用流式刷写的方式进行升级，而是先将升级包保存到 ECU 本地存储，然后进行安装。智能 ECU 的升级通常采用私有协议，通过升级代理(update agent)接收 OTA 主控的升级包和控制命

50、令，根据主控的指令使用本地安装程序(Installer)完成升级包的安装。图 2-8 为智能 ECU 升级单分区方案和双分区方案的系统框架对比。22/136 图图 2-8 智能智能 ECU 升级方案示意图升级方案示意图 单分区方案通常包含主系统分区和更新子系统分区，以及用于存储升级包的缓存区域。正常系统功能相关软件运行在主系统分区，更新子系统是一个最小功能系统仅用于实现软件安装功能。该方案软件更新流程：系统正常运行在主系统分区，同升级代理从 OTA 主控接收升级包文件，并保存在升级包缓存区，升级包接收完成后由进行解密、签名认证，接收到 OTA 主控安装命令后，升级代理将 ECU 切换至更新子系

51、统，在子系统中通过安装程序将升级包安装到主系统分区，替换分区中的旧版本软件，安装完成后系统重启切换到新的主分区软件版本。智能 ECU 双分区升级方案 智能 ECU 双分区方案与单分区相似，双分区方案具有两个结构完全相同的系统分区，两个分区都具备升级代理和安装程序的功能。系统默认运行在 A 系统分区，有新版本软件需要更新时，可以通过升级代理从 OTA 主控接收升级包，并直接通过安装程序将其安装到 B 系统分区中，整个更新过程不影响 ECU 正常功能使用。该方案软件更新流程：系统正常运行在 A 系统分区，同升级代理从OTA 主控接收升级包文件，并保存在升级包缓存区；升级包接收完成后由进行解密、签名

52、认证；接收到 OTA 主控安装命令后，A 系统分区安装程序将缓存中的升级包安装到 B 系统分区；收到 OTA 主控激活命令后将系统启动引导标志设置为B系统分区，重启系统后切换运行B系统分区新安装的软件版本。23/136 2.2.3.2 车载端关键技术（1）OTA 主控主控 电源管理 由于整车升级时间较长，且要确保车辆处于安全状态，因此需要管理升级过程中各个控制器的工作状态。如果车辆在熄火状态下升级，考虑到长时间的电池电量消耗，在升级之前要对车辆的现有电量进行检查，升级过程中需要设计电源管理策略对升级与不升级的控制器、耗电的电器件进行差异化管理。如果控制器由于不可控的意外导致升级异常，也应处于低

53、功耗模式，降低对整车电量的消耗。车辆控制 对于影响车辆安全的升级，整个升级过程需要保持在一种安全状态，因此，OTA 主控需要具备一定车辆功能控制能力，根据不同的升级类型，控制车辆的功能状态。异常处理 在 OTA 传输过程中，外界干扰或者其他因素导致刷写异常或者中断，车载ECU 必须支持软件回滚、断点续传、丢失重传等处理机制。（2）OTA 相关协议相关协议 标准协议 支持软件刷写和软件升级的标准过程，方便 OTA 的开发、测试和集成，如传统 ECU 支持 UDS 协议、AUTOSAR AP 的 UCM。UDS，即统一诊断服务，主要用于车外诊断设备通过车辆诊断口连接车内总线，并向控制器请求控制器内

54、部信息或向控制器传输数据。FBL 规范定义了控制器要实现软件刷写所需遵循的软件架构，并且定义了刷写时需要使用哪些 UDS服务，以及这些服务之间的顺序关系。使用这些 UDS 诊断服务，可以命令控制器擦除原有内存中的软件数据，接收新的软件数据并写入到内存，最终执行新的软件程序。传统 ECU 基本采用的都是基于 UDS 协议的软件刷写这种升级方式。AUTOSAR AP，即自适应平台，是由软件更新配置管理器（UCM）提供了处理软件更新请求的服务。UCM 负责在 AP 上更新，安装，删除和保留软件记录，实现了软件包管理，确保以安全可靠的方式更新或修改 AP 上的软件。UCM 24/136 Master

55、提供了一种标准的平台解决方案，通过与多个 UCM 之间协调和分配车辆内的包，实现 AUTOSAR AP 的软件更新。私有协议 除了升级遵从标准协议的传统控制器，OTA 还需要支持智能 ECU 的升级。智能 ECU 通常带有操作系统并且自身具有升级能力，作为升级对象，需要从 OTA主控模块或者云端获取升级包，并与 OTA 主控进行信息交互，实现升级的触发和升级信息的反馈。对于这部分升级所涉及到的升级包分发和升级控制，现在并没有统一的定义和标准，各家车企和供应商的实现方案也各异。（3）ECU 端升级技术端升级技术 差分升级 相对于整包升级，差分升级方案不仅可以节省 MCU 内部的资源空间、还可以节

56、省下载和升级过程中的功耗。从另一个角度说，通过将差分部分下发到设备保证了软件版本的安全性。差分升级的流程如表 2-8，图 2-9、2-10 所示。表表 2-8 差分升级基本流程差分升级基本流程 步骤 内容 原始版本提取 从目标 ECU 中提取出当前安装的软件版本，以便与新版本进行比较。新版本生成差分包 将新版本的软件与当前版本进行比较，找出两者之间的差异。这些差异可能是代码的新增、修改或删除。生成差分包时，通常使用一些压缩和差异算法，例如哈希函数、二进制比较等，以便减少差分包的大小。差分包传输 将生成的差分包传输到目标 ECU。由于差分包只包含实际更改的部分，因此传输时间会大大减少，尤其是在网

57、络带宽有限的情况下。差分包合并 目标 ECU 接收到差分包后，使用算法将差分包中的更改与当前软件版本进行合并。这可能涉及将新增的代码插入到现有的代码中，可选择修改现有代码，或者删除不再需要的代码。软件验证和更新 合并差分包后，对新软件版本进行验证，确保它在目标 ECU 上正常运行。如果一切正常，系统将完成升级过程，新版本的软件将被激活并开始运行。差分的实现方式主要有两种：基于文本文件的差分和基于二进制文件的差分，其区分在于对比文件的差异，前者是基于逻辑上的，后者是基于物理上的。在升级时，通过与制作过程对应的还原工具，将差分包还原后写入到存储器中，保证写入后的内容与目标版本内容一致。25/136

58、 图图 2-9 差分差分计算过程计算过程 差分计算程序接收旧版本 v1.0 与新版本 v1.1 后生成差分升级包 v1.0-v1.1-update.patch。ECU 端从云端下载差分升级包 v1.0-v1.1-update.patch 后，开始后续的差分还原操作。图图 2-10 差分还原过程差分还原过程 差分还原算法输入参数为旧版本安装包 v1.0 与差分升级包 v1.0-v1.1-update.patch。通过差分还原算法处理后得到最新的完整升级包 v1.1。ECU 端安装 v1.1 完整升级包实现升级目标。安全启动 安全启动(Secure Boot)用于保证固件启动的代码受信任的安全保证

59、机制，它通过在引导加载过程中，对加载固件进行检验，从而防止加载和执行恶意代码。固件的每一步加载都经过数字签名认证，而每一步签名认证的根证书中的密钥需要与固化在芯片内部不可修改的签名密钥匹配，从而行成一个完整信任链。安全校验 ECU 端需要具备对所安装软件包进行完整性校验和真实性校验的能力，这要求 ECU 有能力对更新数据进行签名验证。传统的 ECU 刷写过程通常只通过循环冗余校验验证更新数据的完整性，而无法验证其真实性，存在被刷写非法软件的风险。2.2.4 人机交互 2.2.4.1 人机交互要素分析 26/136 车端的人机交互主要体现在信息娱乐系统上，覆盖到 OTA 的整个过程，包括信息提示

60、、用户确认、关键信息显示等。人机交互过程需要考虑的要素大致可以分为两个方面，即法规符合性和使用便利性，如表 2-8 所示。表表 2-9 人机交互要素分类及示意人机交互要素分类及示意 人机交互分类人机交互分类 要求要求 法规符合性 符合 GB汽车软件升级通用技术要求 使用便利性 版本信息可查看 升级功能可设置 升级信息提示 升级前用户可以选择升级方式，并且支持升级包下载进度的展示，和用户手动取消下载。下载完成后，用户需要再次确认是否升级。升级中显示升级条件的检查，需要实时显示进度；如果条件不满足，要给予用户明确的提示。如果出现异常情况要进行回滚，可以明确提示回滚状态和及其进度。升级后提示升级的结

61、果成功或失败。2.2.4.2 人机交互方式分类 基于实际业务要求，各家 OEM 的 OTA 人机交互方式各有差异，本节共总结 6 种主流升级方式，并针对营运车辆与非营运车辆使用性质不同，分别展开分析，具体如表 2-9 所示。表表 2-10 人机交互方式分类人机交互方式分类 升级方式升级方式 营运车辆营运车辆 非营运车辆非营运车辆 离车升级：升级过程会影响用户使用车辆功能，在升级包下载完成、确认用户离车后进行升级条件检查，条件满足开始升级。运营公司的车辆管理平台远程管理车辆升级 无感升级：升级过程不影响用户使用车辆功能，升级完成后版本切换需要用户确认，系统重启后即可实现版本切换，用户无需等待升级

62、包写入的过程。无感升级可通过 AB 分区技术来实现。立即升级：用户在车机端点击确认升级后，立即发起升级条件检查，条件满足开始升级。车辆回归单位后，统一安排升级 预约升级：用户通过车机或手机端 APP 设置预约升级的时间，当到达设定的时间点，车辆自动检查是否满足升级条件，条件满足开始升级。通过运营公司的车辆管理平台确认授权并设置顶约升级时间 延时升级：用户通过车机或手机端 APP 确认授权升级后，不会立即开始更新，而是在 OEM 设定的时间(比如凌晨)，车辆自动检查是否满足通过运营公司的车辆管理平台确认授权 27/136 升级条件，条件满足开始升级。手机远程升级：用户收到升级通知后，可通过手机端

63、 APP 进行版本检查，通过手机下发下载、升级或者取消等指令的操作，并且在 APP上实时查看下载和升级的过程、升级结果。向车主的手机端 APP发送升级通知 28/136 第三章 汽车远程升级（OTA）政策法规标准研究 汽车软件在线升级具备经济、高效的显著特征，但对原有汽车管理模式带来了新的挑战，需要综合分析国内外汽车创新管理模式和最佳应用实践，从产品管理、技术发展角度提出针对性建议，以应对复杂多变汽车安全形势、保护消费者合法权益和社会公共安全。本章首先梳理国内外政策法规及标准现状、总结我国政策法规标准面临的问题，最后构建 OTA 标准体系，促进汽车产业高质量发展。3.1 国内外政策法规发展现状

64、分析 3.1.1 联合国发布软件升级强制法规 联合国欧洲经济委员会世界车辆法规协调论坛（UN/WP.29）成立的智能网联汽车 OTA 安全任务组 TFCS/OTA，提出关于网络安全和信息保护措施的指南文件。联合国以此任务组提出的研究报告为基础，制定智能网联汽车 OTA 安全专用国际法规 UN R155（信息安全与信息安全管理系统）和 UN R156（软件升级与软件升级管理系统）。两项法规已于 2021 年 1 月正式生效，新车型实施时间为2022 年 7 月，所有车型实施时间为 2024 年 7 月是特殊用途或小批量生产车辆实施 UN R156 的截至日期2。UN R155/R156 法规适用

65、于 M 类、N 类及至少装有 1 个控制单元的 O 类车辆。UN R155 落实车辆网络风险管理，提供安全可靠的软件更新，确保车辆安全不受影响。UN R156 包含软件升级管理体系的合规性要求、对车型认证的要求及认证车型的变更与扩展等要求，为车辆制造商建立汽车软件管理体系、梳理相关定义和完善软件服务能力提供了重要的参考，法规示意图如图 3-1 和 3-2 所示。2022 年 6 月 WP.29 第 187 次全体会议上审议通过了适用于和缔约方的关于网络安全和软件更新的统一规定建议案。该建议案将与 UN R155 和 UN R156 尽可能保持一致，未来此建议案的实行，也将为1998年协议书缔约

66、国的中国在制定有关汽车网络安全的法规和/或车辆软件 29/136 升级及过程的法规提供指导。图 3-1 UN R155 信息安全与信息安全管理系统目录 图 3-2 UN R156 软件升级与软件升级管理系统目录 3.1.2 欧盟扩充软件升级型式批准制度 欧盟以欧洲型式批准（European Type Approval）制度来管理机动车辆。整车批准指令历经换代，从 70/156/EEC（废止）、2007/46/EC（废止）到 2018 年 5 月发布的法规（EU）2018/858关于机动车及其挂车以及用于此类车辆的系统、部件和单独技术单元的批准和市场监督 和2019年11月发布的法规(EU)20

67、19/2144关于机动车辆及其挂车以及用于此类车辆的系统、部件和单独技术单元的型式认证要求，涉及其一般安全性和保护车辆乘员和易受伤害的道路使用者。法规(EU)2019/2144 作为法规（EU）2018/858 中规定的型式批准程序的监管法规，共 30/136 同规定了欧盟的型式批准流程（如图 3-3 所示）。图图 3-3 欧盟产品管理流程图欧盟产品管理流程图*Annex I 联合国法规(UN Regulation)清单*Annex II 技术要求及拒绝授予型式认证的实施日期 2022 年 3 月欧盟提出的车辆安全无限量、小批量和特殊用途的全自动驾驶车辆的技术要求授权法案征求意见稿3，其中提出

68、法规(EU)2018/858 应在其附件 IV 生产程序一致性中引入 UN R156，并制定了条款过渡计划，详见表3-1。表表 3-1 条款过度计划条款过度计划 年限年限 过渡条款过渡条款 自 2022 年 7 月6 日起 若注册后的车辆所执行的软件升级影响了车辆型式审批技术参数等特性，且不符合法规（EU）2018/858 对于软件升级的规定，则国家当局应拒绝对新车型授予欧盟整车型式认证或国家型式认证。若注册后的车辆所执行的软件升级影响了车辆型式审批技术参数等特性，但符合法规（EU）2018/858 对于软件升级的规定，则国家当局不得拒绝对新车型授予欧盟整车型式认证或国家型式认证。自 2024

69、 年 7 月7 日起 若制造商执行的软件升级影响了车辆型式审批技术参数等特性，且不符合法规（EU）2018/858 对于软件更新的规定，则新车的合格证书不再适用，且应禁止车辆的注册、投放市场或投入使用。若车型不符合法规法规(EU)2018/858 对于软件更新的规定，国家主管部门应拒绝对新车型授予供应商欧盟整车型式认证或国家型式认证。小批量生产的车辆或特殊用途车辆不符合法规(EU)2018/858 对于软件更新的规定，国家主管部门应拒绝授予欧盟整车型式批准或国家型式批准 自 2026 年 7 月7 日起 若车辆不符合法规(EU)2018/858 对于软件更新的规定，则小批量生产的或特殊用途新车

70、合格证书不再适用，并且应禁止车辆的注册、投放市场或投入使用。新库存车的合格证书不再适用，若车辆不符合法规(EU)2018/858 对于软件更新的规定，则应禁止车辆的注册、投放市场或投入使用。31/136 3.1.3 美国对以修复为目的的远程升级活动加强召回管理 美国汽车认证制度包括安全认证和环境保护认证，其中：安全认证（DOT 认证）为自我认证，环保类的 EPA 认证和加州 CARB 认证为强制性认证。汽车适用的 DOT 认证法规包括技术类美国联邦机动车安全标准（FMVSS）系列和管理类 49 CFR 500 系列法规。美国国家公路交通安全管理局（NHTSA）是 DOT 认证的主管部门。美国国

71、家环境保护局（EPA）是 EPA 认证主管部门，获得 EPA认证方可准入美国市场（加州需要空气资源委员会（CARB）认证）4。NHTSA和 EPA 可对已生产和组装的汽车整车、设备或零部件实施抽检，若达不到安全和环保法规要求，则责令制造商在规定限期内实施整改，并要求其对已销售产品进行召回。美国车辆产品管理流程如图 3-4 所示。图图 3-4 美国车辆产品管理流程美国车辆产品管理流程 当前，NHTSA 要求制造商对以弥补不合理安全风险为目的的修复活动（包括软件升级）实施召回，并要求制造商告知汽车所有者、经销商和其他人用于解决缺陷的软件升级活动，无论该活动是否影响产品安全5。但因为 NHTSA 担

72、心对召回规定的更新可能导致汽车风险等级的降低，汽车质量受到媒体和公众的较少监督，产品缺陷的持续存在，仍暂时沿用由国家交通和机动车辆安全法案(National Traffic and Motor Vehicle Safety Act)、有关加强运输设备收回、责任确定和文件记录法案(TREAD)规定的适用于物理召回的政策5。由于 NHTSA 施行的召回制度无法充分适应网联车辆，导致政府对车辆软件和网络安全的监督有限，车企或无意识或有意识的利用汽车召回管理疏漏。表 3-2 列举的美国软件升级事件可对中国法律法规制定起到借鉴作用。表表 3-2 美国美国软件升级事件软件升级事件 事件事件 分析分析 20

73、15 年，黑客通知菲亚特克莱斯勒汽车公司（FCA），虽然车辆自身功能存在缺陷与不良行为者的干预 32/136 声称通过利用汽车信息娱乐系统中的漏洞可以远程控制收音机、雨刷器、发动机等。在 NHTSA 的压力下，FCA 启动对 140 万辆汽车和卡车的召回流程。FCA 通知消费者下载安全补丁，或去经销商处进行软件升级6。FCA 虽然同意召回车辆，但声称网络风险不是安全缺陷；NHTSA 对此表示不同意，但未将网络安全正式归类为缺陷7。所导致的缺陷之间存在差异，不能笼统的将网络风险理解为缺陷。但一事一案给市场监管机构造成混乱，使得相关法规标准的修立刻不容缓。2018 年 5 月，特斯拉针对消费者报告

74、对 Model 3制动距离过长的测试结果，在几天之内推出软件升级将制动距离缩短了近 20 英尺。并得到 消费者报告的推荐。此类软件升级是在发现问题后快速推送的，新软件存在未进行充分检测的安全风险。2019 年，一名司机在使用特斯拉半自动自动驾驶技术时撞到一辆卡车的侧面，造成致命事故。特斯拉随后推出软件升级，增加通过检测方向盘脱手次数并决定是否任务回退人类驾驶员的功能，期望以此消除车祸隐患。当时的召回政策未涉及软件相关安全缺陷，因此特斯拉不用遵守召回流程。目前，许多与软件相关的问题并未被 安全法 正式认定为“安全缺陷”，导致 NHTSA 所执行的召回流程不适用于由软件驱动的网联车辆，尽管严重的软

75、件设计问题可能导致死亡。2022 年 8 月，NHTSA 对特斯拉 Autopilot 系统造成的事故开展正式调查。因为大多数事故是在天黑后碰撞到现场安全设施，例如急救车灯、照明箭头板和路锥等8。因此在 NHTSA 开展调查期间，特斯拉用OTA 方式更新了“急救车车灯检测”功能，该功能使特斯拉汽车能够在光线不足的情况下更好地检测急救车车灯9。需要从制度和技术上防范制造商通过软件升级掩盖正在被监管部门调查的汽车缺陷；还需要有标准可依地评估软件更新是否起到了掩盖缺陷的作用。3.1.4 日本对远程升级事前、事中、事后进行监管 日本道路运输车辆法（Road Transport Vehicle Act）

76、是汽车认证制度的法律依据，由日本国土交通省(MLIT)负责执行，其他政府相关部门按照车、人（驾驶员和行人）、路三要素分别制定相关法律或者提出相应的限制要求10。道路运输车辆法规定汽车应满足保安基准的要求，汽车产品市场准入认证要求，定期技术检查要求，以企业自主召回为主的召回要求等。日本汽车型式指定制度流程图如图 3-5 所示。33/136 图图 3-5 日本汽车型式指定制度流程图日本汽车型式指定制度流程图*日本三类认证制度型式指定制度、共通构造部型式指定制度、进口汽车特别对应制度 2020 年 4 月生效的日本道路运输车辆法修正案，针对配备自动驾驶设备的汽车，规定了申请软件升级的企业需要具备的企

77、业能力要求、组织结构和系统要求、一致性要求，软件升级作为召回措施的要求，企业需要承担的义务等，如表3-3所示。对于明确知道升级后不会影响安全标准的例如座舱域的软件升级，不需要对具体升级活动进行申请。该修正案规定若车辆制造商使用外部供应商提供的软件，则制造商和供应商皆可作为具体升级活动的申请机构11。表表 3-3 MLIT 审核项目审核项目 要求要求 详细规定详细规定 企业能力要求 申请人应同时符合 UN R156 中软件升级管理体系（“SUMS 技术标准”）和 UN R155 中网络安全管理体系（“CSMS 技术标准”）。系统要求 申请人应制定组织架构和流程来监督汽车软件的设计、生产、被改装车

78、辆的网络安全。升级后车辆保安基准符合性要求 通过软件升级而改变的车辆零部件的结构、装置和功能应符合各项保安基准。若软件升级改变了型式批准，并且申请人申请具体修改的批准，则申请人需要证明其已获得车型改装的批准。3.1.5 我国各部委政策法规管理现状分析 3.1.5.1 工信部加强 OTA 备案管理，提升生产企业管理能力，保障产品生产一致性 工业和信息化部（以下简称“工信部”）作为指导推进行业体制改革，实施产品公告管理的职能部门，2010 年发布的车辆生产企业及产品生产一致性监督管理办法明确对车辆生产企业及产品公告中的车辆生产企业及其产品进行 34/136 生产一致性监督管理，并将在车辆生产、销售

79、、注册登记等环节进行监督检查。2021 年 7 月发布的关于加强智能网联汽车生产企业及产品准入管理的意见已对产品生产准入后的企业 OTA 活动进行监督。2022 年 4 月发布的关于开展汽车软件在线升级备案的通知是关于加强智能网联汽车生产企业及产品准入管理的意见等有关规定的具体实施措施，该通知把升级活动备案分成三部分，即企业管理能力备案、车型及功能备案和具体升级活动备案，其中具体升级活动备案需要企业在每次实施升级活动前持续履行备案义务，并提交至相应备案系统1。预计后续将根据备案实际开展情况对具体升级活动的分级备案流程不断完善。表表 3-4 工信部发布的工信部发布的 OTA 相关政策法规列举相关

80、政策法规列举 序号序号 名称名称 部门部门 主要内容主要内容 1 关于加强智能网联汽车生产企业及产品准入管理的意见（2021.07）工信部 围绕总体要求、数据和网络安全管理、软件在线升级、产品管理、保障措施等方面提出 11 项具体内容 2 关于开展汽车软件在线升级备案的通知（2022.04）工信部装备中心 规定如何开展汽车软件在线升级备案工作，规定了备案范围、备案要求、备案工作流程、实施安排、企业责任等。3.1.5.2 市场监管总局加强 OTA 技术召回监管，积极开展技术评估及深度安全测试 国家市场监督管理总局（以下简称“市场监管总局”）作为负责市场和产品质量安全监督的职能部门，于 2012

81、年所发布的缺陷汽车产品召回管理条例及其实施办法规定对由于设计、制造、标识等原因存在缺陷的汽车产品进行召回管理并指导企业实施。在 OTA 技术得到汽车制造商和供应商广泛应用后，市场监管总局近几年发布多项 OTA 相关管理政策，如表 3-6，明确将 OTA 作为企业提供主动服务或召回的技术手段，并通过沙盒监管主动、柔性、事前的监管方式开展 OTA 等新技术新功能深度安全测试，在进一步提高应急处置能力、防范和化解安全风险的同时，积极鼓励企业技术创新、倡导最佳安全实践，助力汽车产业繁荣健康、安全有序发展。1 备案系统全称“汽车软件在线升级备案系统”（网址为 https:/ota.miit- 表表 3-

82、6 市场监管总局发布的市场监管总局发布的 OTA 相关政策法规列举相关政策法规列举 序号序号 名称名称 部门部门 主要内容主要内容 1 缺陷汽车产品召回管理条例（2012.10）国务院 明确汽车生产者对缺陷汽车的召回责任，保障消费者的人身健康和财产安全，明确了汽车缺陷的定义、汽车召回的目的、汽车召回实施主体和措施、汽车召回的监督管理、生产者的召回义务、消费者参与汽车召回活动的相关内容。2 缺陷汽车产品召回管理条例实施办法（2015.11）国家市场监管总局 对生产者的信息报告义务、缺陷调查及召回实施程序、监管职责和法律责任等相关内容做进一步细化和明确，使之更具有可操作性，以满足监管需要。3 关于

83、进一步加强汽车远程升级（OTA）技术召回监管的通知（2020.11）国家市场监管总局 明确规定 OTA 可作为消除汽车产品缺陷、实施召回的方式，不得隐瞒车辆缺陷、规避召回责任，OTA实施过程中发生安全事故需及时调查分析。4 关于汽车远程升级（OTA）技术召回备案的补充通知（2021.6）国家市场监管总局质量发展局 实施 OTA 的企业需要在发布前 5 个工作日内提交汽车远程升级（OTA）安全技术评估信息表和电子版升级包。安全技术评估信息表包括车辆基本信息；本次升级目的、推送策略、涉及的系统/零部件、是否双分区、失败处理机制及用户告知流程等功能和技术信息；升级包功能安全、信息安全、台架、整车测试

84、报告；云平台日志管理；车端/云平台/传输管道采用的安全策略等五项。5 机动车排放召回管理规定（2021.4）国家市场监管总局、生态环境部 建立市场监管总局与生态环境部联合工作机制，其中召回管理基本程序、企业责任及时限要求与缺陷汽车产品召回管理条例及其实施办法基本保持一致，同时生产者需要通报的机动车排放危害信息也考虑了 OTA 技术服务的影响。6 家用汽车产品修理更换退货责任规定（2022.1）国家市场监管总局 已在真实案例处理中明确了 OTA 技术作为三包修理手段并计入累计次数和时间。7 关于试行汽车安全沙盒监管制度的通告（2022.2）市场监管总局、工信息化部、交通运输部、应急部、海关总署

85、明确规定使用 OTA 技术的汽车可作为沙盒监管的对象进行深度安全测试。3.1.5.3 网信办等加强 OTA 过程中的网络安全与数据安全管理 36/136 我国移动通信行业发展非常迅猛，网络产品缺陷、漏洞、数据安全等风险得到较早预防，已在中华人民共和国网络安全法、中华人民共和国数据安全法、中华人民共和国密码法等一系列已出台的法律法规中提出应对措施。目前针对 OTA 技术已明确规定了软件包的安全和漏洞检测评估。然而基于智能网联汽车分层解耦、跨域共用的特征，OTA 技术在应用层和计算平台的升级服务范围更广、覆盖度更深，使得车辆安全防护变得更困难。因此针对 OTA技术带来的新型网络安全、数据安全风险，

86、安全保障体系亟须健全完善。表表 3-5涉及网络安全、数据安全的涉及网络安全、数据安全的 OTA 相关政策法规列举相关政策法规列举 序号序号 名称名称 部门部门 主要内容主要内容 1 网络产品安全漏洞管理规定（2021.07）工信部、国家互联网信息办公室、公安部 规范漏洞发现、报告、修补和发布等行为，明确网络产品提供者、网络运营者、以及从事漏洞发现、收集、发布等活动的组织或个人等各类主体的责任和义务；鼓励各类主体发挥各自技术和机制优势开展漏洞发现、收集、发布等相关工作。2 汽车数据安全管理若干规定（试行）（2021.08）国家互联网信息办公室、国家发展和改革委员会、工信部、公安部、交通运输部 倡

87、导汽车数据处理者在开展汽车数据处理活动中坚持“车内处理”、“默认不收集”、“精度范围适用”、“脱敏处理”等数据处理原则，减少对汽车数据的无序收集和违规滥用。3 关于开展汽车数据安全、网络安全等自查工作的通知（2021.09）工信部 装备中心 要求各整车企业对汽车数据安全、网络安全、软件在线升级、驾驶辅助功能情况开展自我核查并填写汽车数据安全、网络安全等情况自查表。其中软件在线升级部分侧重 OTA 的功能实现，对在线升级管理、实施等情况信息展开调查。4 关于加强车联网网络安全和数据安全工作的通知（2021.09）工信部 在网络安全和数据安全基本要求、加强智能网联汽车安全防护、加强车联网网络安全防

88、护、加强车联网服务平台安全防护、加强数据安全保护、健全安全标准体系等六方面提出 17 项具体要求。5 数据出境安全评估办法（2022.07）网信办 旨在落实网络安全法、数据安全法、个人信息保护法的规定，规范数据出境活动，保护个人信息权益，维护国家安全和社会公共利益，促进数据跨境安全、自由流动，切实以安全保发展、以发展促安全。3.2 国内外标准发展现状分析 37/136 产业发展、标准先行。标准在推动新技术新功能发展过程中发挥着基础引领作用。OTA 技术的规模化应用推动了汽车、通信、大数据、安全等跨领域行业组织及社会团体的标准制定工作。本文基于 OTA 通用技术要求、OTA信息安全、OTA 技术

89、管理、OTA 工程开发应用和软件接口 5 个分类，共梳理出国内外标准 27 项，如表 3-7 所示，并遴选关键标准进行概述。表表 3-7 国内外国内外 OTA 相关标准进展相关标准进展 分类分类 标准名称标准名称 标准组织标准组织 标准状态标准状态 OTA 通用技术要求 1 UN R156软件升级与软件升级管理系统 WP.29 已发布 2 GB汽车软件升级通用技术要求 TC114 汽标委 提交报批 OTA 信息安全 1 UN R155信息安全与信息安全管理系统 WP.29 已发布 2 ITU-T X.1373智能交通系统通信设备的安全软件更新功能 ITU 修订中 3 IEEE-ISTO 610

90、0.1.0.0:Uptane Standard for Design and Implementation IEEE-ISTO 已发布 4 GB/T 40861-2021汽车信息安全通用技术要求 TC114 汽标委 已发布 5 GB/T 40856-2021 车载信息交互系统信息安全技术要求及试验方法 TC114 汽标委 已发布 6 GB/T 40855-2021电动汽车远程服务与管理系统信息安全技术要求及试验方法 TC114 汽标委 已发布 7 GB汽车整车信息安全技术要求 TC114 汽标委 提交报批 8 GB/T汽车诊断接口信息安全技术要求 TC114 汽标委 起草 9 T/CCSA 4

91、80-2023 车联网在线升级(OTA)安全技术要求与测试方法 CCSA 通标协 已发布 10 YD/T基于公众电信网的车载远程通信终端网络安全技术要求 CCSA 通标协 已送审 11 T/CSAE 1010-2018智能网联汽车车载端信息安全技术要求 CSAE 中国汽车工程学会 已发布 12 T/CSAE 252-2022 智能网联汽车车载端信息安全测试规程 CSAE 中国汽车工程学会 已发布 13 T/CSAE汽车软件升级信息安全测试规范 CSAE 中国汽车工程学会 已送审 OTA 技术管理 1 GB/T基于远程升级技术的汽车产品召回实施要求 TC463 全国产品缺陷与安全管理标准化技术委

92、员会 起草 OTA 工程开发管理 1 ISO 24089 道路车辆 软件升级工程 ISO 已发布 38/136 分类分类 标准名称标准名称 标准组织标准组织 标准状态标准状态 2 ST-OTA-1 System Requirements Definition ST-OTA-2 Data Requirements Definition ST-OTA-3 HMI Requirements Definition ST-OTA-4 Vehicle System Requirements ST-OTA-5 In-vehicle Rewrite Requirements Definition ST-OTA

93、-6 In-vehicle Communication Specification ST-OTA-7 Process Requirements Document ST-OTA-8 Vocabulary ST-OTA-9 Compliance Test Specificateion-OTA Master ST-OTA-10 Compliance Test Specificateion Target ECU JASPAR 已发布 3 R21-11 Requirements on Update and Configuration Management R21-11 Specification on

94、Update and Configuration Management AUTOSAR 已发布 软件接口 1 ISO 231502023 道路车辆 自动驾驶功能的传感器与数据融合单元之间的数据通信逻辑接口 ISO 已发布 2 GB/T智能网联汽车车控操作系统技术要求及试验方法 TC114 汽标委 立项在研 3 GB/T智能网联汽车车载操作系统技术要求与试验方法 TC114 汽标委 立项在研 4 软件定义汽车服务 API 参考V3.0 CAAM 中国汽车工程协会 已发布 5 T/CSAE 234-2021 智能网联汽车 线控转向及制动系统数据接口要求 CSAE 中国汽车工程学会 已发布 6 T/

95、CSAE智能网联汽车设备抽象与感知服务接口规范 CSAE 中国汽车工程学会 已报批 7 T/CSAE智能网联汽车融合感知系统 系列标准 CSAE 中国汽车工程学会 立项在研 8 T/CSAE车控操作系统功能软件架构及接口要求 CSAE 中国汽车工程学会 已发布 3.2.1 通用技术要求 强制性国家标准 GB汽车软件升级通用技术要求报批稿规定了汽车软件升级的管理体系要求、车辆要求、试验方法、车辆型式的变更和扩展、说明书。该标准预计 2024 年实施，实施后将可能成为具备 OTA 功能的汽车产品的准入强检依据。UN R156 和国标对整车企业的软件升级管理体系（SUMS）建设和型式认证方面提出了具

96、体要求。UN R156 法规中，要求车型需要具有 RXSWIN，相同描述在国标中被定义为软件识别码（SWIN）。国标中对 SWIN 的定义为由车辆制造 39/136 商定义，用于表示与准入或认证相关系统中软件信息的专用标识符。其中 UN R156 和国标在 SUMS 体系建设方面的要求基本相同，在车辆型式认证中，针对车辆要求中在线升级附加要求国标新增了两种规定，以及车辆要求的试验方法。可以参考图 3-6、3-7 所示。图图 3-6 管理体系建设要求管理体系建设要求12 图图 3-7 车辆型式认证车辆型式认证 40/136 3.2.2 信息安全 2017 年 3 月，国际电信联盟电信标准分局(I

97、TU-T)发布建议书（标准）X.1373 智能交通系统通信设备的安全软件更新功能并在 2022 年进行修订。本标准首先提出软件升级通用车载模型包括信息设备、电子控制单元(ECU)和车辆移动网关(VMG)等，以及软件升级通用过程。之后定义软件升级的传输消息类型和格式。2022 年修订版本提出了三种软件升级的主要威胁和针对三种威胁的安全要求并在附录中做出详细解释。三种威胁包括：对升级软件的损坏、拒绝服务攻击、更新过程受损和恶意入侵。2021 年 10 月，全国汽车标准化技术委员会（以下简称“汽标委”）发布了 GB/T 40855-2021电动汽车远程服务与管理系统信息安全技术要求及试验方法。本标准

98、在 GB/T 32960-2016电动汽车远程服务与管理系统技术规范（3 部分）基础上对车载终端内的硬件、固件、软件系统、数据存储、网络端口传输安全、远程升级功能、日志功能的信息安全要求及试验方法做出规定。并提出平台间安全通信协议、数据单元加密等要求。2021 年 10 月，汽标委发布了 GB/T 40861-2021汽车信息安全通用技术要求。本标准将保护对象分为车内系统和车外通信两大类，并阐述对应的保护要求。本标准规定了软件升级活动应确保软件和近距离、远距离通信的真实性、保密性、完整性、可用性、访问可控性、抗抵赖性、可核查性及可预见性。列举了软件升级活动可能带来的固件覆写、升级包重放、非法软

99、件安装及拒绝正常软件升级等信息安全风险。2023 年 10 月，强制性国家标准 GB汽车整车信息安全技术要求已提交报批。报批稿中参考 UN R155 法规附录 5 以及 UN R156 法规中的信息安全相关部分（表 A1 4.3.3 有关脆弱性/威胁的描述、漏洞及攻击方法示例，以及表 B2 中有关的缓解措施）并基于国内行业发展现状，对“软件升级安全要求”提出具体技术要求。2023 年 10 月，中国通信标准化协会提出的行标车联网在线升级(OTA)安全技术要求与测试方法已发布。该标准对 GB汽车整车信息安全技术要求未涉及的车联网平台安全管理制定了推荐性要求，标准涵盖 OTA 云端服务平台安全、通

100、信链路安全、OTA 应用安全等方面的技术要求与测试方法。41/136 2018 年，中国智能网联汽车产业创新联盟（CAICV，以下简称“创新联盟”）发布的 T/CSAE 1010-2018智能网联汽车车载端信息安全技术要求和 2022 年发布的 T/CSAE 252-2022智能网联汽车车载端信息安全测试规程共同规定了车载信息交互系统的硬件、通信协议与接口、操作系统、应用软件、数据的信息安全技术要求和试验方法。其中T/CSAE 1010-2018 提出了软件升级包来源鉴别、身份认证、用户确认、安全工况下升级等的技术要求，而 T/CSAE 252-2022 提出了对应的测试方法。2022 年 8

101、 月，创新联盟立项了团体标准 T/CASE汽车软件升级信息安全测试规范。该项标准聚焦汽车 OTA 升级前的服务平台验证、升级中的访问控制和密码技术应用，及升级后的处置过程中的测试方法，为车辆制造商、第三方检测认证机构提供体系化、实操性强的测试认证依据，引领产业和企业的发展，提升产品和服务的市场竞争力。3.2.3 OTA 技术管理 为规范缺陷汽车产品召回，全国产品缺陷与安全管理标准化技术委员会（TC463）在缺陷汽车产品召回管理条例及其实施办法发布后，还陆续出台了 GB/T 34402-2017 汽车产品安全 汽车风险评估与风险控制指南 GB/T 39603-2020 缺陷汽车产品召回效果评估指

102、南、GB/T 40914-2021 汽车产品召回 预警规则、GB/T 41047-2021汽车产品召回过程追溯系统技术要求等国家推荐标准。提出以风险评估方法衡量产品缺陷，以风险水平高低制定风险控制策略；以召回活动实施、召回措施和召回活动满意度为召回效果评估依据；以风险等级、召回效果评估、涉及生产者数量为启动预警依据等规定。为政府部门和生产者做出决策和问题处理提供实用性指南。2021 年 TC463 发布基于远程升级技术的汽车产品召回实施要求国标研制计划，将基于远程升级技术的汽车产品信息备案与召回实施基本流程，提出“云管端”等环节的技术实施规范，以及全流程的安全要求。3.2.4 工程开发管理 2

103、023 年 2 月，国际标准化组织（ISO）发布 ISO 24089道路车辆 软件升级 42/136 工程。ISO 24089 形成了一整套从管理到功能开发、再到开展升级的规范。该标准首先规范软件升级的相关术语，建立软件升级活动相关参与方的沟通基础。之后指导企业建立 OTA 支撑设施和车辆产品的软件升级功能。以及开发验证软件升级包和实施软件升级相关的流程的规范。ISO 24089 发布后除指导企业实施OTA 外，也可被认证机构采用，作为整车厂和供应商具备软件升级能力的认证标准，支撑软件升级管理体系（SUMS）的落地实施。作为更加落地的标准，ISO 24089 除了重申 UN R156 中涉及

104、SUMS 认证和车辆型式审批等的要求，还考虑了 OEM 与供应商协同开发的工作方式；软件升级带来的车辆功能安全风险和预期功能安全风险；给出功能开发和升级活动中的不同示例等。UN R156 与 ISO 24089：2023 的映射关系见附件 1 自 2020 年起，日本汽车软件平台与架构标准化组织（JASPAR）陆续发布了10 个 OTA 相关标准,在 OTA 的管理流程、HMI、车端功能、数据等方面，建立了一套较为全面的 OTA 标准体系,预计率先在日系车企中落地。10 个标准名称和内容如表 3-8 所示。表表 3-8 JASPAR OTA 标准列表标准列表 标准编号标准编号 标准名称标准名称

105、 标准内容简介标准内容简介 ST-OTA-1 System Requirements Definition 定义 OTA 系统架构和基本功能 ST-OTA-2 Data Requirements Definition 定义 OTA 相关数据构成与数据流 ST-OTA-3 HMI Requirements Definition 定义 OTA 的 HMI 功能要求 ST-OTA-4 Vehicle System Requirements 定义车端 OTA 系统组成部分以及流程 ST-OTA-5 In-vehicle Rewrite Requirements Definition 定义车端 ECU

106、刷写的功能要求 ST-OTA-6 In-vehicle Communication Specification 定义车端 ECU 刷写流程 ST-OTA-7 Process Requirements Document 定义 OTA 业务的管理流程 ST-OTA-8 Vocabulary 定义 OTA 系统的术语 ST-OTA-9 Compliance Test Specificateion-OTA Master 定义 OTA Master 的标准符合性测试规范 ST-OTA-10 Compliance Test Specificateion Target ECU 定义目标 ECU 的标准符合性

107、测试规范 汽车开放系统架构（AUTOSAR）联盟设置了专门的工作组 WG-UCM(Update and Configuration Management)制定 OTA 相关标准，已发布版本为 R21-11 的Requirements on Update and Configuration Management 和 Specification on Update and Configuration Management。UCM 标准定义 PackageManagement 服务接口，43/136 支 持 软 件 升 级 包 的 下 载、安 装 和 激 活 等 过 程。UCM Master 定 义

108、VehiclePackageManagement 服务接口，支持整车升级包的下载，并把整车升级包拆分成软件升级包分发到相关的 UCM 模块，触发 UCM 的软件升级。UCM Master还有支持用户确认及查询升级先决条件是否满足等功能。3.2.5 软件接口 基于 SOA 理念的电子电气架构开发,使互相分散的 ECU 及对应的功能以模块化、标准化的方式集中在域控制器中，以服务的方式提供。各服务在交互过程中通过标准化接口连接，使得远程升级变得更加方便，实现了软硬件分离。车用操作系统作为运行于车内的程序集合，理论上全部支持更新的软件可通过远程升级进行迭代，然而不同整车出于安全性、可靠性的考虑，以及服

109、务之间存在的耦合性，还不能发挥 OTA 的潜力。当前，车用操作系统主要分为车控操作系统（安全车控操作系统、智能驾驶操作系统）和车载操作系统13。针对操作系统接口及整车 OTA 关键共性技术的研发，将支持软件的持续更新、海量关键信息流的高数据通讯、车路云多源算力分配，创造“常用常新”的全生命周期用车体验。智能网联汽车逻辑语义及设备服务接口标准见下。2021 年 ISO 发布的 ISO 231502021道路车辆 自动驾驶功能的传感器与数据融合单元之间的数据通信逻辑接口定义了车内环境感知传感器（例如，雷达、激光雷达、摄像头、超声波）与融合单元之间的逻辑接口。并把逻辑接口分为提供探测、技术特征、对象

110、识别（例如，潜在移动对象、道路对象、静态对象）以及传感器性能监测等接口。该标准在 2023 年开始新一轮修订，并于 2023 年 5月开始实施。2020 年 12 月，中国汽车工业协会成立软件定义汽车工作组对 SOA 软件架构进行服务化分层解耦，将 SOA 软件架构分成应用层、原子服务层、设备抽象层、基础平台层。2022 年 6 月 28 日 SDV 工作组发布软件定义汽车服务 API参考V3.0 行业规范征求意见稿，包含原子服务 API 参考、设备抽象 API 参考两部分。两部分标准分别定义车身控制、热管理、运动控制、能量管理、智驾域、人机交互功能域的原子服务 API 接口和设备抽象 API

111、 接口的功能和参数。2020 年 4 月，创新联盟立项的 T/CSAE智能网联汽车融合感知系统架构设 44/136 计规范、T/CSAE智能网联汽车融合感知系统数据格式规范、T/CSAE智能网联汽车融合感知系统数据服务规范 三项系列标准共同规定了自动驾驶多模态融合感知系统可提供的算法组件以及对应数据服务接口、数据格式。2023 年 6 月,创新联盟发布了 T/CSAE 车控操作系统功能软件架构及接口要求在遵从国标智能网联汽车车控操作系统技术要求及试验方法的操作系统功能软件总体架构的基础上，规定了功能软件面向应用软件提供的针对驾驶自动化功能的配置接口、加载接口和数据交换接口的技术要求。并且可无缝

112、接入符合 ISO/FDIS 23150-2021 的感知数据。2023 年 11 月,创新联盟报批了 T/CSAE智能网联汽车设备抽象与感知服务接口规范。标准在借鉴 ISO 23150 基础上，突出各传感器的独立逻辑接口，规定了车内传感器（单目智能摄像头、双目摄像头、激光雷达、4D 毫米波雷达等）以及 V2X 设备（OBU 设备）的设备抽象服务和感知服务的接口规范。3.3 我国现有政策法规标准问题分析 3.3.1 亟需加强跨部委跨行业协作，创新监管模式 我国对 OTA 管理已有积极进展，从目前已公布的信息看，工信部监管侧重于 OTA 升级系统能力以及每次升级所变更功能是否合规，而市场监督管理总

113、局的监管更偏向于软件升级的实施过程是否合规，OTA 升级结果是否达到预期等1。建议两部委依据职能定义，进行一定的分工和侧重，注重备案报送系统间互通、数据共享与数字共治，协同制定 OTA 备案管理国家标准，规范备案管理，提高审核效率。目前各部委对 OTA 的合规管理主要采用升级前备案的方式，由生产厂家按照统一的备案要求进行备案和审核，升级所需的备案周期相同。然而，不同功能的升级频率不同，升级对安全的影响也不同。例如车机移动应用（APP）的迭代频率高，对汽车的一致性和安全性影响较小；问题修复类软件升级对安全性影响较大但升级需求急迫。因此亟需探索创新监管模式，通过标准化的手段评估升级内容对车辆、系统

114、、功能、参数的影响，建立更加灵活的差异化合规管理方式，整体提升审核效率。45/136 3.3.2 缺乏相关管理标准与技术标准 缺少缺少软件软件产品管理类标准。产品管理类标准。随着汽车行业智能化、网联化、电动化的快速发展，汽车逐渐由机械驱动向软件驱动过渡，由于政府对车辆软件和网络安全的监督管理有限，部分政府产品管理法规无法适应智能网联汽车的快速健康发展。例如家用汽车产品修理更换退货责任规定条例（以下简称三包政策）规定汽车产品在包修期内出现质量问题修理者应当免费修理。目前，三包政策中并未对通过软件升级方式为汽车部件级、系统级、整车级的版本更新和修正做出详细定义，导致三包维修案例处理中修理者和消费者

115、对软件升级是否属于汽车产品修理存在争议和误解14。因此建议对三包政策以及配套标准 GB/T 29632-2021 家用汽车产品三包主要零部件种类范围及三包凭证做出适应性修订。并且应有计划的推动软件安全和网络安全缺陷术语与定义、软件质量管理、升级包关键字段格式要求、升级包解析技术要求等标准研制，有法可依的管理软件产品。缺少软件升级影响评估类标准。缺少软件升级影响评估类标准。工信部、市场监管总局发布的部门规章，以及 GB 汽车软件升级通用技术要求，均提出了对软件升级影响评估的需求。UN R156 及其解释文件规定了企业软件升级管理体系需识别升级系统与其他系统（影响安全、网络安全、防盗、能效和环境行

116、为的系统）在功能和软件层面的相互依赖性等。然而，国内外政策标准只限于原则性规范，行业内尚无标准定义软件升级的安全性边界，无法甄别车辆安全参数或安全性能是否更改，存在企业可能采用 OTA 隐瞒车辆缺陷、规避召回责任的风险。缺少供应商能力缺少供应商能力管理管理类标准。类标准。ISO 24089道路车辆软件升级工程标准虽然在 UN R156 基础上制定了车辆、系统、ECU、软件包以及云平台等 OTA 支撑设施的设计和开发规范，并关注到整车厂与供应商之间的流程裁剪定制等需求，但仍然缺乏实施细则，还需要相应技术标准详细规定；JASPAR 和 AUTOSAR 虽然定义了服务接口和 ECU 的刷写流程，可作

117、为 ISO 24089 的有效补充，但是未涉及整车厂与供应商之间的业务流程，供应商的软件升级管理能力要求和安全防护措施。因此建议出台行业统一规范，在标准化企业软件升级管理能力的同时，46/136 认证供应商的能力，为 OTA 技术生态发展持续助力。3.4 构建 OTA 标准体系，支撑政府监管，赋能生态繁荣 依据上文国内外标准现状梳理和问题分析，可初步将远程升级标准归为基础通用、核心技术与产品应用、配套技术三类，标准体系结构图可参见图 3-8 所示。基础通用标准基础通用标准包括 OTA 技术术语和定义、通用技术要求、信息安全标准。术语和定义术语和定义标准用于统一 OTA 技术的基本概念。通用技术

118、要求通用技术要求标准主要包括保证车辆安全性、一致性能力方面的要求，车辆需要履行的对用户和社会等义务要求；信息安全信息安全标准主要针对车载系统、云平台之间的通信、数据、软硬件安全提出风险评估、安全防护要求。核心技术与产品应用核心技术与产品应用标准标准包括升级系统的影响评估、工程开发管理、OTA 技术管理、体验评价标准。影响评估影响评估标准主要由软件升级前与其他系统的相关性识别，升级中和升级后对车辆、系统、功能、参数的影响评估组成；工程开发管理工程开发管理标准主要规范 OEM 与供应商相互协作的全生命周期软件开发和质量管理要求，以及软件供应商的软件升级管理体系要求；OTA 技术管理技术管理标准主要

119、包括为政府部门决策和问题处理提供指导的标准，例如规范生产厂家采用软件升级方式实施技术服务、修理、更换、召回的技术要求，升级内容与备案内容一致性评估，软件升级未取得预期效果的补救措施，备案系统技术要求等；体验评价体验评价标准主要针对主观、客观两种维度对软件升级实施流程进行评价和约束。配套技术标准配套技术标准包括基础软件平台、软件接口等。基础软件平台基础软件平台标准主要包括面向服务的架构（SOA），底层软件开发标准规范；软件接口软件接口标准主要定义新型EE 架构下不同功能领域或子系统之间的逻辑接口，减少待升级部件和周边部件的接口适配开发、联调和测试工作量，支持部件独立升级。47/136 图图 3-

120、8：标准体系结构图：标准体系结构图 48/136 第四章第四章 汽车远程升级汽车远程升级(OTA)产业生态研究产业生态研究 随着 OTA 技术的上车应用，汽车产品在售出之后仍可持续完善现有功能并增加新功能；其升级对象已经从早期的 T-BOX 基础功能发展到安全性要求相对较低的座舱、娱乐等系统，如今正在进一步覆盖与驾驶安全相关的智能驾驶、动力等系统。同时，随着车联网技术的发展，OTA 技术在汽车上的应用规模逐渐扩大，入行企业越来越多，软件及服务能力持续提高，产业链重心逐步向软件倾斜。本章从 OTA 的产业发展现状、技术对产业生态的影响及负面案例与启示等三方面进行分析，描绘产业链图谱，助力产业持续

121、、高效、优质发展。4.1 汽车 OTA 产业发展现状 4.1.1 汽车 OTA 的业务模式 汽车 OTA 系统在“云管端”架构下，有相对统一的业务环节，吸引着众多参与者，共同构成了多样化的业务模式（OTA 系统的“云管端”示意图可参见图 4-1）。可概括为以下两种：部分车企选择自主建立企业级的 OTA 运行平台，打通OTA 云平台、企业 IT 系统等之间的数据链接。大多数车企对于云平台建设、信息安全等环节相对陌生，选择与 OTA 供应商合作，快速形成量产方案，实现整车产品 OTA 功能。图图 4-1 OTA 系统的系统的“云管端云管端”架构（示意）架构（示意）汽车 OTA 产业链上游主要由 O

122、TA 解决方案提供商、内容提供商组成，中游为提供 OTA 服务的整车厂，下游则是安装 OTA 升级程序的车辆产品及享受升级 49/136 服务的用户。OTA 产业生态图谱如图 4-2 所示。(1)产业链上游格局 OTA 产业链上游是解决方案提供商，主要分为专业的 OTA 解决方案商、部分整车企业及部分传统一级供应商等。解决方案提供商是专注于 OTA 技术本身研发与应用的软件科技公司，如爱瑟福、艾拉比、科络达等。部分整车企业利用自身优势资源建设专业的软件开发体系、研发软件系统，通常可覆盖 OTA 自主开发业务，典型的如小鹏、蔚来、上汽零束等。汽车传统一级供应商一般通过并购 OTA 技术公司的方式

123、快速切入 OTA 领域，如哈曼收购 Red Bend、安波福（原德尔福）收购 Movimento、风河收购 Arynga 等。OTA 内容提供商的升级服务主要在应用软件内部进行，以车载娱乐与导航功能为主，如视频、音乐、地图等车载服务的更新；升级内容来自相应服务的运营商，如腾讯、网易、百度等。(2)产业链中游格局 OTA 产业链中游主要由整车企业组成，向下游用户提供 OTA 服务，在产业链中拥有较强的话语权。整车企业普遍认识到应通过软件差异化和 OTA 赋予的持续升级能力去塑造产品竞争力，但各企业之间 OTA 研发应用进度不同。总体来看，新势力企业的整车产品在 OTA 能力方面领先于传统企业的整

124、车产品，主要体现在升级对象、升级频次以及探索软件付费等新的商业模式上。(3)产业链下游格局 OTA 产业链下游主要是汽车产品及其用户，现阶段 OTA 服务覆盖乘用车、商用车等多种类型，动力方面新能源汽车、传统汽车在技术上都可实现。OTA 服务的受众以更加注重科技体验的年轻用户为主。图图 4-2 汽车汽车 OTA 产业生态构成产业生态构成 50/136 4.1.2 我国汽车 OTA 现状 根据市场监管总局对生产企业备案 OTA 召回和技术服务活动的要求，截至2022 年 8 月底，市场监管总局已收到 100 余家企业提交汽车远程升级(OTA)安全技术评估信息表1100 余份，涉及 OTA 超过

125、1 亿辆次。4.1.2.1 整体趋势分析 根据企业提交信息表数据显示，2021 年 OTA 涉及数量呈爆发式增长趋势。2021 年企业报告 OTA351 次，涉及车辆 3424 万辆，较 2020 年同期分别上升了55%和 307%。2022 年截至 8 月底，已收到企业报告 OTA435 次，涉及车辆高达4300 余万辆，高于 2021 年全年数据。对比 2022 年与 2021 年企业上报的 OTA情况（图 4-3 所示），涉及车辆数整体呈快速上升趋势，尤其是 3 月份增长迅速，单月涉及车辆数突破 1000 万辆。同时，2022 年 OTA 涉及车辆次也显著高于 2021年同期水平。图图

126、4-3 2021 年与年与 2022 年累积涉及车次变化趋势年累积涉及车次变化趋势 从涉及车辆动力类型来看，新能源汽车占天然优势，是传统燃油汽车的 1.16倍。但传统燃油汽车 OTA 涉及的车辆次也呈快速增加趋势，由 2021 年较 2020年增长 121.0%（图 4-4 所示）。可见，OTA 不再是新能源汽车的专属，传统燃油车领域也在不断发劲。51/136 图图 4-4 2020 年年-2022 年年 OTA 涉及动力类型分布涉及动力类型分布 从升级领域来看，OTA 涵盖了娱乐系统、信息与数据系统、整车、动力系统、座舱系统等 9 大功能域。其中，信息与数据系统、娱乐系统和整车系统是目前OT

127、A 的三大主流系统，占总涉及车辆次的 74.24%（图 4-5 所示）。FOTA、SOTA仍是目前 OTA 主流，但 2022 年涉及配置更新的次数增长明显，较 2020 年与 2021年的合计数量增长了 22 倍（图 4-6 所示）。图图 4-5 OTA 系统涉及车次和辆次数统计系统涉及车次和辆次数统计 52/136 图图 4-6 OTA 类型统计类型统计 从升级目的来看，增加用户体验，增加新的功能需求和修复BUG是目前OTA的主要目的，占总涉及车辆次的 94.85%。其中，因增加用户体验升级占比 34.41%；因增加新功能或新需求而升级占比31.81%；因修复BUG/漏洞而升级占比28.6

128、3%（图 4-7 所示）。但涉及修复 BUG/漏洞的占比相对较高，相关漏洞是否会引发缺陷，需进一步强化风险分析及监管能力。图图 4-7 OTA 原因统计原因统计 4.1.2.2 企业 OTA 情况分析 从平台类型来看，公有云涉及车辆次占比最大，占 56.69%，但是私有云及混合云的占比也逐年增高。云平台部署位置涉及全国 15 个省市区，上海、北京、广东、浙江、河北 5 个省市涉及的 OTA 次数占总次数的 92.16%。从升级时长来看，70%以上的 OTA 升级包下载和安装速度基本控制在 30 分钟内。其中，升级包下载时间在 30 分钟以内的约占 63%，安装时间在 30 分钟以 53/136

129、 内的约占 87%（图 4-8 所示），说明 OTA 单次升级过慢问题已得到有效改善。（1）升级包下载时间统计）升级包下载时间统计 （2）升级包安装时间统计）升级包安装时间统计 图图 4-8 OTA 升级包下载和安装时间统计升级包下载和安装时间统计 从安全措施来看，断点续传、回滚和重试是三种主要的防失效保护方式。其中，采取断电续传机制的占总涉及车辆次的 77.88%，回滚机制的占 59.50%，重试机制的占 55.24%。升级包签名、通讯链路加密以及双向身份验证是主流的三种防护机制。其中，采取升级包签名的占总涉及车辆次的 85.18%，通讯链路加密的占 77.53%，双向身份认证的占 71.2

130、9%。不管是防失效保护方式，还是信息防护机制，企业都采取了多方式并用模式。54/136 4.2 OTA 对汽车产业生态的影响分析 4.2.1 企业竞争力发展分析 对于整车企业，OTA 带来的是产品全生命周期持续研发问题，要求重塑传统产品开发模式，独立软件开发周期与流程体系，组建专门的软件开发团队，以软件开发流程体系带动整车级 OTA 运转。对于供应商企业，Tier 1 供应商、OTA供应商与独立软件开发商需要思考如何更好地支撑、配合整车企业的 OTA 运营和管理工作。4.2.1.1 OTA 带来整车开发流程重塑 OTA 带来的产品全生命周期持续研发问题，对于传统以硬件开发为主导的汽车行业提出巨

131、大的挑战，要求车企重塑产品开发模式。实现整车级 OTA 更需要在汽车开发设计之初就纳入规划，而不能仅将其视作打补丁的方法。传统整车开发过程执行严格的“需求、设计、验证、确认”V 模型开发流程，在量产前锁定硬件状态、软件版本、标定数据。智能汽车产品开发带有典型的软硬解耦特征，硬件研发随量产结束，而软件的研发和升级将伴随整车全生命周期过程，尤其在售后阶段需通过 OTA 为产品增加全新开发的功能及服务(图 4-9 所示)。在面对复杂而频繁的软件 OTA 需求时，严谨规范的 V 模型将与敏捷开发等增量开发模式相结合，进化出更加灵活的开发流程。图图 4-9 整车级整车级 OTA 是车企软件开发流程体系的

132、重要组成部分是车企软件开发流程体系的重要组成部分 4.2.1.2 整车企业与供应商的合作模式与关系的变化 55/136 智能化网联化赋予汽车新价值与新属性，也为车企重塑整零关系、掌握产品定义权提供新的机会。车企越来越重视 OTA 所牵引的商业价值，意识到掌握数据资源、构筑新时代技术壁垒的重要性，激发了软件技术自研的强烈愿望。传统产业分工体系的垂直分层、链条式的采购-供应关系（如图 4-10 所示）被打破，转而形成扁平化、多方合作式的网状生态（如图 4-11 所示）。研发合作模式也从一级供应商掌握核心技术、车企被动集成，转向车企主动掌握系统级自主研发能力、定义开发标准、主导生态建设。图图 4-1

133、0 传统采购传统采购-供应关系供应关系 图图 4-11 多方合作的网状生态多方合作的网状生态 OTA 的发展加速了软硬件解耦的进程。在全新的产业生态模式下，随着软件产品形成独立的开发体系，整车企业与系统供应商、软件供应商之间呈现出新的合作关系，甚至各自扮演的角色会发生变化。部分软件供应商将进一步向价值核心靠拢，成长为新的一级供应商；车企可能绕过传统一级供应商，直接接触原二级供应商，典型如车企、域控厂商、算法厂商之间的合作。越来越多的供应商将成为合作伙伴的角色，围绕车企形成开发生态圈，支持全生命周期的 OTA 服务。在 OTA 理念的影响下，未来的软件开发逐渐转向功能驱动、面向架构的合作开发模式

134、，软件供应商将与车企建立更加长期、紧密的合作关系，支持整车产品全生命周期内的更新升级。当前车企建设软件研发能力的方式主要有成立软件研发部门、成立软件子公司、与软件供应商战略合作三种方式。OTA 技术方案的开发应贯穿整车开发全过程，除 OTA 方案提供商外，车企、一级供应商、芯片供应商、软件供应商等方也应协同一致，从整车项目开发伊始布局整车 OTA 功能。在新的更为复杂的产业生态中，OTA 同样影响着未来硬件供应商对整车产品的支持方式。硬件预埋的思路下，车企将开发品类更少、功能高度统一的硬件平台，适配多种车型产品及不同的产品配置，硬件采购和管理成本的下降将为通 56/136 过 OTA 获得软件

135、方面的长期收入赢得更大利润空间。而车企的成本控制策略也将使硬件供应商长期面临成本控制的压力，硬件通用化、模块化将会成为应对挑战的关键措施。另一方面，通过 OTA 进行软件升级不可能突破原生硬件性能的限制，因而从硬件上如何支持全生命周期的更新升级同样是硬件供应商的研究重点。目前来看，除硬件可插拔外，在同一硬件平台上应用部分可编程的芯片如MPSoC（Multi-Processor System on Chip）等实现动态功能改变也是未来可能的发展方向。4.2.1.3 整车企业核心竞争力转向软件及服务能力 OTA 是实现车载软件持续更新迭代的技术手段，整车企业重视 OTA 能力的背后是汽车行业在软件

136、定义汽车理念影响下正在经历着深刻的变革。智能网联汽车时代，整车企业将围绕软件和服务能力构建核心竞争力，实现在汽车全生命周期内持续盈利，最大程度地提升产品价值。通过软件订阅长期收费的商业模式被越来越多的车企采用，尤其是在自动驾驶及智能座舱领域为车企创造了切实的收入及利润增长，价值链重心正在由硬件向软件、由售前向售后、由产品向服务转移。在研发能力建设方面，为应对汽车产品在生命周期内的持续升级、快速迭代，整车企业必须掌握一定软件自研能力，特别是对于能够构建差异化竞争力的关键软件。随着软件集成复杂度持续增加，车企将越发重视系统架构能力，支持软硬件解耦，设计统一的软件接口和数据传输格式，实现域内及跨域的

137、软件集成、数据互通。在开发管理能力建设方面，软件规模越来越大，研发项目的进度与成本存在管控风险。车企最终需要建立起大型软件的集成和管理能力，支撑软件产品的独立开发、验证、交付，实现软硬件开发的有效解耦与持续协同。4.2.2 商业模式发展分析 OTA 是未来车企向用户提供增值服务的关键手段，开辟全新的商业模式，其背后可能带来汽车产业大生态的变化。整车企业需要从制造者向运营者的角色转变。一方面要管理好用户需求，另一方面要整合产业生态，打通“研产供销服”57/136 各环节。将盈利点从整车销售，向持续的功能升级服务转移。4.2.2.1 汽车产品价值重心向软件倾斜 随着汽车 OTA 的深度参与，软件销

138、售成为汽车行业的新的商业模式。随着汽车电动化、智能化的程度提升，硬件逐步趋同，差异主要集中在软件领域，汽车消费价值链由硬件转向软件。尤其在智能汽车时代，汽车不再是一成不变的大宗消费品，智能化系统在 OTA 的加持下将加速实现迭代和进化。汽车可持续功能迭代升级持续优化长尾问题。场景和功能上的延展使得消费者在整个汽车生命周期上的总花费提升，这其中除了传统硬件和售后服务，还包含了更多的持续性软件和增值服务消费，其价值占比也不断提高。安永预计，中国汽车产业终端消费中软件及服务的占比到 2030 年将超过 40%（图 4-12 所示）。图图 4-12 中国汽车消费价值链占比（中国汽车消费价值链占比（20

139、20-2030E）15 传统整车企业的商业链条止于整车销售，后续的维修、保养等环节一般不由车企直接提供服务。智能汽车的一大特点是整车的全生命周期运营，软件付费服务正在成为车企创收的新渠道，OTA 则提供了该模式的技术基础。预计未来软件服务收入及利润占比持续增加，车企将以全生命周期视角重新审视经营战略，“硬件成本化、软件利润化”将取代传统意义上的硬件成本优先战略。4.2.2.2 车企的用户运营模式升级 OTA 具有强用户体验的属性，从用户体验的角度，OTA 不仅仅是简单的功能交付，而是享受全生命周期的内容服务，“研产供销服”各环节均需要开发、生 58/136 产、市场及质量、售后、IT 等团队的

140、协同配合。产业链关系的变革，使更多的车企选择直面用户、与车主直接对话，汽车销售渠道格局正变得更为多元化。车企与车主之间不再仅以车辆作为商品进行一次性买卖，而是通过整车产品的交易，衍生出一系列与车辆全生命周期相关的服务体验，与车主形成持续互动，形成商业模式的闭环（如图 4-13 所示，图片引用自智能汽车云服务白皮书）。图图 4-13 车企用户运营模式的变化（车企与车主关系转变）车企用户运营模式的变化（车企与车主关系转变）15 对于整车企业来说，OTA 重新定义了售后阶段运营内容。OTA 将被纳入汽车软件大体系中，售后服务基于企业的 OTA 系统开展，具备面向 SOA 全新电子电气架构的整车升级能

141、力、汽车软件版本管理能力、售后软件服务能力等。在这个过程中，数据资源都将作为核心资产贯穿整个变革。OTA 过程中的数据可反馈给产品以获取更精准的升级方向和需求定义，持续优化产品体验。如何从大量繁杂且业务类别多样的数据中挖掘出真正能赋能业务的价值数据，并通过“穿针引线”，将数据打通串联并实现高阶的应用，将是运营模式升级能否成功的核心要素。4.2.2.3 OTA 服务商正在向汽车一级供应商发展 随着汽车产品中软件价值占比逐渐提高，车企除了加速建设软件研发能力，59/136 对汽车软件全生命周期管理的需求也同样迫切。随着车企不断深入探索，OTA 开始在更多品牌、更多车型上得到普及，用户规模、数据规模

142、持续扩大，管理上的压力向上游传导，迫使车企不断提升软件管理能力。然而，对于现阶段大部分车企来说，围绕软件展开的开发、管理、服务等能力并非强项，就 OTA 系统而言，更是涉及云平台、运营服务等一系列相对陌生的环节，面临建设经验和技术不足、试错成本高的挑战。另一方面，相关监管日益严格，OTA 内容、网络安全、数据安全的合规性都将成为 OTA 系统方案的组成部分，尤其是在智能汽车背景下，未来车企合规成本将持续增加。现阶段车企搭建 OTA 体系的主流模式是与专业的 OTA 解决方案商合作，由其提供 OTA 功能开发服务乃至车云一体化的 OTA 全生命周期管理方案；在产品售后阶段，双方共同运营 OTA

143、更新服务。OTA 解决方案商的优势在于技术专业化，更重要的是其方案经过长期验证、具备可复制性、能够快速部署，最大限度地缩短整车产品开发周期。随着 OTA 功能价值凸显、OTA 系统化开发的复杂度提升，OTA 服务商也正在向整车一级供应商发展。部分软件研发实力较强的整车企业选择自主研发并建立 OTA 服务体系的道路，一方面反映出车企对软件升级中商业价值的重视，另一方面，也是出于完全掌握车辆数据的现实需求。智能汽车的发展、技术迭代均需要数据驱动，海量的用户及车辆数据已成为车企核心资产，较难无限制开放给供应商；未来车企将更加重视私有云平台的建设，保障对数据的控制权、使用权。正视车企的上述考虑和需求，

144、帮助车企建立体系化的、更加独立的 OTA 运营能力，或将成为下一阶段 OTA 服务商发展的关键方向。4.2.2.4 消费者对汽车产品的新认知 OTA 改变了汽车产业化的消费和服务模式，缩短了智能汽车从研发到量产的周期，通过 OTA，用户能够得到更加灵活且持续优化用车体验。在购车环节，高阶软件功能事实上成为选配，一方面为消费者提供了可选择的余地，另一方面新车价格也会有所下降，在购置税、促销方案等处让消费者切实得到优惠。在使用环节，车企探索为用户搭建可交流、可反馈的互动平台，让用户问题直达研发端，即使在车辆售出后，仍可通过 OTA 升级相应功能，即实现共创开发模式。60/136 对于消费者来说，O

145、TA 让其体验到需求被及时理解、及时满足。因此，消费者会乐于见到 OTA 给车辆带来的创新，并逐渐接受为此支付费用，实现软件付费升级的商业模式落地。当用户不必换车也能获得持续迭代的体验时，车主对该二手车的保值预期提高，最终汽车品牌价值将同样得到提升。4.2.3 负面案例与启示 OTA 正在成为智能汽车核心竞争力，消费者享受到了新技术带来的便利体验，但同时也在承担着技术不成熟、功能滥用以及运营欠佳等导致的风险。OTA是一项复杂的系统工程，在技术上是传统汽车电控、移动软件管理、云服务、无线通信等技术的交叉应用，在管理上涉及全生命周期、全流程、整车级的软件开发和远程部署，在运营上需要兼顾用户的升级体

146、验并探索新商业模式。对于企业研发来说，认识到汽车 OTA 的价值、学习借鉴技术和运营上的成功经验固然有益，思考可能面临的风险并了解分析负面案例则可以避开前进道路上的陷阱。以下从三个角度列举和分析 OTA 的失败案例或争议案例。（1）产品设计不成熟：提升 OTA 系统本身的可靠性和鲁棒性 2019 年，某新势力汽车品牌用户在城市主干道行驶途中开启整车 OTA 功能，导致整车功能失效，只能停在主干道上等待。直至 1 小时后升级结束，车辆功能恢复、重新启动。尽管该案例中导致事故的直接原因是车主误操作，但车企应充分认识到大多数用户关注点在功能的实现效果，而不具备对技术的深刻理解，因此在设计 OTA 激

147、活逻辑时应充分考虑车辆状态及用车场景，从技术上避免误操作。2021 年，某新能源汽车品牌用户在下载更包后对车辆进行 OTA，2 小时后发现车辆无法启动，钥匙按键无反应，车上按键全部失效，车窗无法关，整车如断电一般直接“变砖”，最终被拖去 4S 店。这是一起典型的 OTA 失败事故。越多核心部件与系统参与升级，所带来的风险也越大，可能导致系统故障、失效、甚至可能影响行车安全，维修成本剧增且损害企业品牌形象。在开发中除充分验证OTA技术本身的可靠性外，还应为升级失败设计回滚机制作为安全保障的预案。（2）功能滥用：OTA 不应成为掩盖产品缺陷的手段 2022 年，某新势力品牌因旗下纯电动汽车连续发生

148、自燃事故，借用户参加 61/136 优待活动的机会，对用户车辆进行锁电操作，即通过改变电池管理系统（BMS）控制参数，降低动力电池放电容量，达到控制发热量的目的。但该操作未明确告知用户，且导致续驶里程缩水明显，引发用户维权。该企业进而通过 OTA 多次执行静默升级的方式，消除和掩盖车载系统中的锁电证据。该案例的核心问题在于企业未经用户同意，滥用 OTA 远程更改车辆状态。OTA 与软件升级绑定的宣传方式，正在成为车企美化产品设计问题的手段。在技术实现上，通过 OTA 进行功能增加、性能优化、缺陷召回等没有本质区别，但在企业运营管理以及政府监管上应对 OTA 的目的严格区分，避免 OTA 功能的

149、滥用。（3）运营欠佳：基于 OTA 的付费订阅应针对软件增量功能而非硬件固有功能 2022 年，某传统车企在国内推出后轮主动转向的订阅服务。付费升级后，其后轮转向角度将得到提升，整车转弯直径缩小。功能订阅费用每年近五千元，可提供三个月的免费试用期。同年，另一家传统车企在国外市场推出座椅加热和方向盘加热的订阅服务，根据付费周期设置了不同的订阅价格，同时也支持一次性买断。此两个案例具有相同的运营逻辑用户在线付费，通过 OTA 解锁功能。可以感受到企业在积极尝试付费订阅的新商业模式，但核心的争议点在于其所选功能的价值主要来自硬件，软件 OTA 仅充当开关；消费者订阅后，只有一次功能从无到有的体验，而

150、无法享受软件持续升级的增值服务。这是 OTA 运营内容生态的一次失败尝试，其深层次原因在于企业并没有抓住软件订阅商业模式的精髓。（4）交付“半成品”：OTA 不应成为“画饼”宣传的工具 OTA 技术的出现，使原本购车时敲定功能配置、整车交付即代表开发验证完全的传统理念被打破。先交付“半成品”，之后再在全生命周期内持续升级或优化，塑造了汽车“常用常新”的概念。但消费者购车之后，企业在事前宣传中承诺的 OTA 内容延期交付现象时有发生。典型如多个品牌宣称 2022 年量产城市导航辅助驾驶功能，而直至三季度末仍未见批量向用户车辆进行软件升级。为了追求缩短新车研发周期、快速上市，车企选择将类似智能驾驶

151、系统这种 62/136 高技术复杂度、长开发周期、短时间内不影响用户驾驶的功能通过 OTA 延迟开通，这在业内已不罕见。但企业需要注意的是，销售过程中对整车产品功能、技术的宣传等同于承诺，已经拉高了消费者心理预期，在车辆售出后应按承诺时间通过 OTA 交付功能。第五章第五章 汽车远程升级（汽车远程升级（OTA）安全风险研究）安全风险研究 随着汽车软件升级逐步在智能网联汽车产品中广泛应用，覆盖研发、生产、售后等多个环节，对企业的技术水平和管理能力均提出新的要求。若生产企业OTA 管理不当、OTA 技术不成熟，会加剧功能实现的可靠性风险，使升级后的系统将车辆与驾驶人暴露在未知的危险中。本章首先阐述

152、车联网安全现状，之后结合 OTA 风险评估流程对 OTA 带来的网络安全、数据安全和功能安全风险进行分析，提醒企业规避应用 OTA 技术中面临的各种安全风险。5.1 车联网安全形势分析 伴随智能化、网联化的不断推进，车辆开放连接逐渐增多，“车、路、云、网”数据交互日益频繁，车联网领域的安全风险边界逐渐延伸。车联网信息安全风险主要集中在车端、平台、通信、数据等方面。（1）车端安全风险隐患凸显 一是车载软硬件存在安全隐患。当前，汽车电子电气架构正由分布式向域控集中式架构、整车集中式架构不断发展，步入软件定义汽车时代。车载智能网关、远程信息处理控制单元（T-BOX）、电子控制单元（ECU）等车载联网

153、设备目前尚缺乏较高等级的安全校验机制和安全防护能力，近年来陆续披露出一些安全漏洞隐患。二是车载网络存在安全隐患。CAN、FlexRay 等车载网络协议缺乏安全设计，车内数据传输主要根据功能进行编码，按照 ID 进行标定和接收过滤，部分仅提供循环冗余校验，缺乏重要数据加密、访问认证等防护措施，导致车载网络容易受到嗅探、窃取、伪造、篡改、重放等攻击威胁，难以保障车载网络的安全性。（2）车联网平台服务面临的攻击威胁加剧 63/136 近年来，汽车远程服务、在线升级（OTA）平台、车辆调度平台等业务服务快速发展，用户的规模逐步扩大，日渐成为网络攻击的重要目标。由于车端用户可通过车联网平台进行信息交互、

154、远程操作，一旦遭受网络攻击控制，可被利用实施对车辆的远程操控，造成严重后果。（3）车联网通信安全面临挑战 当前，联网车辆数量和通信需求不断增长。在“车-云”通信场景下，网络隔离不到位、通信协议存在漏洞隐患、访问接入缺乏安全认证等问题突出。“车-设备”通信场景下，受限于设备性能等因素，通信安全认证机制尚不完善，存在拒绝服务攻击等漏洞隐患，可导致 WiFi、蓝牙、智能钥匙失效16。在 OTA 功能实现过程中，云端、车端、通信链路、升级包等关键环节均存在被攻击和篡改等安全隐患。OTA 网络安全态势分析如图 5-1 所示。图图 5-1 OTA 网络网络安全安全态势态势分析图分析图 5.2 OTA 风险

155、评估方法 基于网络安全、数据安全及功能安全风险评估理论基础、现有的威胁分析以及实践经验，结合汽车本身的复杂特性，可建立以资产为核心的汽车OTA 远程升级安全风险评估模型。OTA 风险评估方法具体参照 ISO 26262 道路车辆 功能安全工程、ISO/SAE 21434 道路车辆 网络安全工程、SAE J3061信息物理汽车系统网络安全指 64/136 南等标准，主要评估对象包括 OTA 相关项、组件及漏洞。在相关标准中定义有 STRIDE、攻击树、EVITA、HEAVENS、OCTAVE、PASTA 等威胁分析和风险评估方法论，对这些方法论的对比和融合后归纳如表 5-1 所示。表表 5-1

156、OTA 风险评估归纳表风险评估归纳表 风险评估对象风险评估对象 威胁分析方法威胁分析方法 可行性分析方法可行性分析方法 影响分析方法影响分析方法 OTA 相关项和组件 STRIDE 模型 攻击树模型 VAST 模型 故障树模型 基于攻击潜力的方法 S（安全）、F（财务）、O（可操作性）、P（隐私）OTA 安全漏洞 STRIDE 模型 故障树模型 基于 CVSS 的方法 5.2.1 OTA 相关项及组件风险评估 以威胁分析及风险评估分析方法 TARA 为例，建立 OTA 风险评估流程，如图 5-2 所示。65/136 图图 5-2 TARA 风险评估流程风险评估流程 5.2.1.1 安全相关性判

157、定 在进行 TARA 分析前，需要对相关项的功能及其运行环境进行定义，以充分识别出资产（包括内部实体、外部实体、存储数据、数据流等），实体、数据被破坏后带来的危害场景等。相关项定义（Item Definition）的目的是了解分析对象，了解其业务、功能、流程、边界，OTA 相关项边界定义如图 5-3 所示。图图 5-3 OTA 相关项边界定义示意图相关项边界定义示意图 数据流图（Data Flow Diagram）需把该相关项中每个功能用到的数据标识出来，从哪个实体产生，经过哪个实体处理，经过哪个实体转发等。数据流图要素的基本符号如图 5-4 所示。E E 外部实体外部实体 P P 功能单元功

158、能单元 S S 数据存储数据存储 TBTB 信任边界信任边界外部实体外部实体（external entityexternal entity）功能单元功能单元（processing unitprocessing unit）数据存储数据存储（data storagedata storage）数据流数据流(data flowdata flow)信任边界信任边界(trusted boundarytrusted boundary)图图 5-4 数据流图要素的基本符号数据流图要素的基本符号 以 OTA 业务为例，参考数据流图如图 5-5 所示。66/136 图图 5-5 OTA 业务参考数据流图业务参考数

159、据流图 5.2.1.2 资产识别 资产识别（Asset Identification），是识别车辆在使用的过程中需要被保护不受网络攻击的信息，包括了通讯数据、用户隐私数据、ECU 固件、算法等各种类型的信息。资产定义的目的是识别出这些资产，确定每项资产的网络安全属性,从而分析出潜在的损害场景。资产识别过程表如表 5-2 所示。表表 5-2 资产识别过程表资产识别过程表 资产识别输入资产识别输入 资产识别活动资产识别活动 资产识别输出资产识别输出 已构建完成的数据流图 1）识别资产：获得评估对象在外部实体、功能单元、数据存储和数据流四个方面的资产；2）识别危害场景：识别资产由于丧失安全属性而出现

160、的危害场景。1）资产和安全属性；2）危害场景；资产的网络安全属性通常分为机密性(Confidentiality)、完整性(Integrity)、可用性(Availability)、真实性(Authenticity)、授权性(Authorization)、抗抵赖性(Non-repudiation)、新鲜性(Freshness)、隐私性（Privacy）。每一个资产都具有相应的网络安全属性如表 5-3 所示。经以上分析，OTA 过程中所涉及信息安全资产包括：零部件资产：T-BOX、CGW、目标 ECU 及车载总线；数据资产：升级包、升级日志和升级指令等信息；软件资产：零部件上所运行系统和升级管理程

161、序。表表 5-3 OTA 过程涉及的资产和损害情况（示例）过程涉及的资产和损害情况（示例）资产类别资产类别 资产名称资产名称 网络安全属性网络安全属性 危害情况危害情况 67/136 零部件资产 T-BOX 真实性 通过伪造 T-Box 和后台的通讯端口，破坏通讯真实性，使得后台的交互指令发送到非目标对象 CGW 完整性 通过篡改 Gateway 软件的工作逻辑，破坏资产的完整性，导致软件升级过程被恶意干扰 ECU 可用性 通过打乱 ECU 软件的工作进程，使其无法正常工作，破坏软件的可用性，导致软件升级过程无法执行 车载总线 可用性 通过干扰车内信号的交互过程，破坏车内通讯的可用性，导致软件

162、升级过程无法正常执行 数据资产 升级包 完整性 通过篡改待升级软件包的内容，破坏其完整性，构造出恶意软件写入车载 ECU，引起车端功能逻辑错误 升级日志 完整性 通过篡改升级日志内容，破坏数据完整性，导致升级过程的记录信息错误，导致升级过程无法准确追溯 升级指令 真实性 通过伪造升级指令，破坏车内通讯的真实性，导致软件升级过程出现错误 软件资产 系统 可用性 通过打乱 Gateway 软件的工作进程，使其无法正常工作，破坏软件的可用性，导致软件升级过程无法执行 升 级 管 理 程序 可用性 通过干扰升级管理程序通讯，破坏通讯过程的可用性，使得升级交互通讯无法进行 5.2.1.3 威胁分析 威胁

163、场景定义是 TARA 分析的重要环节，TARA 最终输出的风险等级和风险处置决策的对象就是威胁场景。威胁分析过程如表 5-4 所示。表表 5-4 威胁分析过程表（示例）威胁分析过程表（示例）威胁分析输入威胁分析输入 威胁分析活动威胁分析活动 威胁分析输出威胁分析输出 相关项判定 危害场景 1）威胁场景识别，说明造成危害的时机，环境和攻击方法等要素(STRIDE 分析)2）攻击可行性评估：确定进入目标系统的攻击向量的攻击潜力 3）影响分析：根据威胁因素和可能的攻击路径推导出相关项或组件可能受到损害的要素及场景（SFOP 定性,HEAVENS）1)威胁场景 2)攻击可行性评级 3)影响评级 威胁场

164、景应通过目标资产、相关网络安全资产受到的威胁，导致网络安全财产受损的原因推导得出。推导方法包括 EVITA,TVRA,PASTA,STRIDE 等。以 OTA 过程中数据资产升级包的完整性、机密性、可用性被破坏为例，威胁场景识别如表 5-5 所示。表表 5-5 威胁场景识别（示例）威胁场景识别（示例）危害情况危害情况 威胁场景威胁场景 篡改待升级软件包内容 完整性被破坏，升级无法正常执行 破解待升级软件包 机密性被破坏，窃取其中的核心算法 干扰升级进程 构造出恶意软件写入车载 ECU，引起车端功能逻辑 68/136 错误，可用性被破坏或者通过非法指令导致车辆运行状态下，非预期地进入升级模式 攻

165、击路径可基于自上而下的攻击树；自下而上的告警日志、以往安全事件确定的漏洞等方式推导得出。对于每一个攻击路径可基于多维度的攻击潜力难度系数得出攻击潜力值，以及攻击可行性等级，如表 5-6 所示。表表 5-6 攻击可行性评估（示例）攻击可行性评估（示例）威胁场景威胁场景 攻击路径攻击路径 攻击可行性评估攻击可行性评估 所需时所需时间间 专业知专业知识识 产品公产品公开性开性 机会窗机会窗口口 装备装备 攻击攻击潜力潜力值值 攻击可攻击可行性等行性等级级 通过篡改/伪造升级包内容，使升级无法正常执行 OTA 平 台 网 页漏洞扫描-网页扫描/系统漏洞-发现下载升级包链接-获取升级包-篡改升级包内容

166、1周（1）外行（0）公开的（0）困难（10）标准（0）10 高（4）CAN 总线监听数 据 流，依 据 UDS 协议要求，找到与网关的通信，获取升级包-篡改升级包内容 1月（4）精通（3）限制（3）适度（4）专攻（4）18 中（3）寻找 T-BOX 的业务逻辑漏洞，获取升级包-篡改升级包内容 1月（4）精通（3）限制（3）适度（4）专攻（4）18 中（3）物 理 拆 解 T-BOX，从车端存储升级包的芯片中提取固件-获取升级包-篡改升级包内容 1月（4）精通（3）限制（3）困难（10）专攻（4）24 低（2）通过获取并破解待升级软件包，窃取其中核心算法 利用社会工程学办法从开发人员或其他相关人

167、员处获取升级包并破解，导致核心机密被窃取 1周（1）外行（0）限制（3）容易（1）标准（0）5 高（4）通过汽车远程升级平台或管理平台数据库暴露的后门端口窃取 1月（4）专家（6）限制（3）无 限 制（0）专攻（4）17 中（3）69/136 升级平台数据库未设置访问权限或其他相关管控措施 1月（4）专家（6）限制（3）无 限 制（0）专攻（4）17 中（3）从T-BOX升级节点控制器或存储芯片中提取升级包 1月（4）专家（6）公开（0）困难（10）专攻（4）24 低（2）通过干扰升 级 过程，导致升级无法正常执行或非法升级 对OTA云平台发起拒绝服务攻击（DoS），占用云平台和T-BOX通信

168、带宽，导致控制器程序包无法下发到 T-BOX 1月（4）精通（3）限制（3）适度（4）专攻（4）18 中（3）伪造升级指令，使车辆执行非预期的刷新动作和升级 1月（4）专家（6）限制（3）困难（10）专攻（4）27 极低（0）影响等级可分为严重（Server）、主要（Major）、中等（Moderate）、可忽略（Negligible）四个等级，并通过危害对功能安全（Safety）、财务（Financial）、可操作性（Operational）、隐私（Privacy）等维度的影响评估来确定危害的综合影响等级和影响值，如表 5-7 所示。在实际的影响等级评估中，也可以采用HEAVENS 方法中提

169、出的定量评估方法，其中安全和财产的影响水平具有较高的权重（01000），操作和隐私方面的损害影响相对较低，权重也较低（0100）。表表 5-7 OTA 影响等级分析（示例）影响等级分析（示例）威胁场景威胁场景 影响等级分析影响等级分析 安全安全 财务财务 可操作性可操作性 隐私隐私 影响值影响值 影响等级影响等级 通过篡改/伪造升级包内容，使升级无法正常执行 可忽略 可忽略 中等 可忽略 1 可忽略(1)通过获取并破解待升级软件包，窃取其中核心算法 可忽略 主要 可忽略 可忽略 100 主要(3)通过干扰升级过程，导致升级无法正常执行或非法升级 严重 可忽略 严重 可忽略 1100 严重(4)

170、70/136 5.2.1.4 确认风险值 通过结合安全风险的业务影响评级和攻击可行性评级，依据风险评估矩阵评定风险等级，确定安全风险的处置优先级，为后续的韧性处置方案设定评级目标。风险值确认过程参见表 5-8。表表 5-8 风险值确认过程表风险值确认过程表 输入输入 风险值确认活动风险值确认活动 输出输出 1）威胁场景 2）攻击可行性评级 3）影响评级 确定每个威胁场景的风险值，风险值可分为：可忽略不计，低危，中危，高危，严重 风险值 根据表 5-9 风险评估矩阵识别风险值 R。表表 5-9 风险评估矩阵风险评估矩阵 风险评估矩阵风险评估矩阵 攻击可行性等级攻击可行性等级 非常低非常低 低低

171、中型中型 高高 影 响 评级 严重的 2 3 4 5 主要的 1 2 3 4 中等水平 1 2 2 3 可忽略不计 1 1 1 1 1=可忽略不计 2=低危 3=中危 4=高危 5=严重 根据表 5-10 进行风险值分析。表表 5-10 风险值分析（示例）风险值分析（示例）威胁场景威胁场景 汇总攻击可汇总攻击可行性等级行性等级 影响评级影响评级 风险值风险值 通过篡改/伪造升级包内容，使升级无法正常执行OTA 平台网页漏洞扫描-网页扫描/系统漏洞-发现下载升级包链接-获取升级包-篡改升级包内容 高（4）可忽略（1）低危（2）通过获取并破解待升级软件包，窃取其中核心算法通过汽车远程升级平台或管理

172、平台数据库暴露的后门端口窃取 中（3）中（3）中（3）通过干扰升级过程，导致升级无法正常执行或非法升级伪造升级指令，使车辆执行非预期的刷新动作和升级 极低（0）高危（4）低危（2）5.2.1.5 风险处置 根据风险处置方案思维导图，借助风险处置库，设计风险处置的韧性方案。在风险处置方案设计完成后，通过再次评估，判断参与风险是否降至风险等级目标。若残余风险仍未达到风险等级目标，需根据业务的实际情况，考虑是否接受 71/136 残余风险或进一步增强处置措施形成最终风险处置方案。风险处置活动参见表 5-11、表 5-12。表表 5-11 风险处置过程表风险处置过程表 输入输入 风险处置活动风险处置活

173、动 输出输出 1）相关项定义 2）威胁情况 3）风险值 对于每种威胁场景，结合其风险值及其等级，确定风险接收、风险缓解、风险规避、风险转移四种中一种或多种风险处置方案。风险处理决定 表表 5-12 风险处置活动（示例）风险处置活动（示例）威胁情况威胁情况 风险值风险值 风险处理方案风险处理方案 通过篡改/伪造升级包内容，使升级无法正常执行OTA 平台网页漏洞扫描-网页扫描/系统漏洞-发现下载升级包链接-获取升级包-篡改升级包内容 低危（2）降低风险：不存在由权威漏洞平台公开发布 6 个月及以上且未经处置的高危安全漏洞；关键零部件应具有存储和隔离敏感数据的安全区域或安全模块；具有防止非授权获取或

174、篡改在安全区域或安全模块中一次性写入的敏感信息的功能 通过获取并破解待升级软件包，窃取其中核心算法通过汽车远程升级平台或管理平台数据库暴露的后门端口窃取 中（3）降低风险：在关键网络节点处，如互联网边界处，合理部署可对攻击行为进行检测、阻断或限制的防护设备；关闭云平台不使用的端口，例如 TCP、UDP 上层应用端口默认全部关闭，并根据实际业务需要开启特定端口（例如 SSH 22、HTTPS 443）；按照一定的安全规则（参数包括：协议类型、端口范围、主机 IP、网段 IP 等）进行访问；配置信息应指定端口进行跨越边界的网络通信，指定端口应配置并启用安全策略。建议只开放业务端口 通过干扰升级过程

175、，导致升级无法正常执行或非法升级伪造升级指令，使车辆执行非预期的刷新动作和升级 低危（2）降低风险：使用安全机制确保传输数据（例如：车辆控制指令等）的完整性和可用性。包括车内网络通信完整性检验采用 MAC、车内网络通信采用SECOC、消息新鲜码等防重放攻击机制；应采用控制策略避免大量集中向 CAN 总线发送数据包，以避免造成总线拥塞和拒绝服务 5.2.1.6 处置跟踪验证 对上述修复的结果进行测试验证，由相关技术人员或第三方根据处置方案进行测试验证。5.2.1.7 残余风险评估 残余风险主要方式产生如表 5-13 所示。针对残余风险应重新进行特定范围 72/136 的风险评估，并识别是否达到可

176、接受风险水平。处于不可接受范围的残余风险须进一步增加相应的管理和控制措施，在所有的残余风险处于可接受范围的水平后，应发布风险声明并加强日常网络安全监测。表表 5-13 残余风险产生方式残余风险产生方式 产生方式产生方式 解释解释 有意识接受的风险 指的是在风险处置阶段，通过风险接受或风险转移方式所衍生的残余风险；已识别但误判断的风险 指的是在风险评估阶段已完成识别的风险项，但由于风险评级识别错误，导致在测试验证阶段发现残余风险无法达到可接受风险水平；未识别风险 指的是在风险处置或测试验证阶段，识别出存在其他安全威胁的风险；5.2.1.8 风险闭环 梳理风险评估流程文档，为后续网络安全日常运维或

177、安全审计提供支持。5.2.2 OTA 安全漏洞风险评估 OTA 安全漏洞指硬件、软件、协议的具体实现或系统安全策略上存在缺陷，从而使攻击者能够在未授权的情况下访问或破坏系统。应对安全漏洞进行识别、风险评估、修复、测试验证等操作以保证系统安全。以下提供了安全漏洞处置流程及技术方法，可用于针对某 OTA 业务场景所涉及零部件和环境进行漏扫，以得出具体漏洞信息。OTA 安全漏洞评估流程见图 5-6。73/136 图图 5-6 OTA 安全漏洞风险评估流程图安全漏洞风险评估流程图 5.2.2.1 漏洞识别 漏洞识别方式：漏洞公告、漏洞扫描、渗透测试、白帽测试等；漏洞类型识别：如 STIRDE 威胁模型

178、中的仿冒、篡改、信息泄露等类型。5.2.2.2 风险评估定级 Common Vulnerability Scoring System（CVSS）提供了一种方法来描述可利用性的主要特征，并生成分值反应其严重程度，使得人们确定处理它们的优先级17。CVSS 评分方法如表 5-14 所示。表表 5-14 CVSS 评分方法评分方法 可利可利用指用指标标 判断场景判断场景 分值分值 攻 击向量 AV 攻击者能够通过网络堆栈攻击易受攻击的组件吗 能通过网络（OSI 第三层）利用该漏洞吗 该漏洞可以在互联网上被利用，或者在没有更多信息的情况下被利用 0.85 漏洞通过有限的物理或逻辑网络被利用，例如蓝牙，

179、WIFI 等 0.62 74/136 攻击者需要物理连接吗 攻击是通过本地应用程序漏洞实施的，或者攻击者能够在本地登录 0.55 攻击者需要物理接触受攻击的组件 0.2 攻 击复 杂度 AC 攻击者能否随意利用该漏洞攻击 攻击者可以总是可以随时利用漏洞 0.77 成功攻击依赖条件超出攻击者控制的情况 0.44 权 限要求 PR 攻击者在攻击之前必须获得组件的授权吗 未经授权的攻击者 0.85 需要管理员权限吗 需要用户级访问权限 0.62(S 变化则为 0.68)需要管理员或系统级访问权限 0.27(S 变化则为 0.5)用 户交互 UI 攻击者需要其他人实施行动吗 攻击者可以在没有用户的交互

180、下完成攻击 0.85 成功的攻击需要用户交互 0.62 CVSS 可利用性值与攻击可行性的映射示例如表 5-15 所示。表表 5-15 基于基于 CVSS 的攻击可利用性映射表的攻击可利用性映射表 CVSS 可利用性值：可利用性值：E 攻击可行性评级攻击可行性评级 2.96-3.89 高 2.00-2.95 中等 1.06-1.99 低 0.12-1.05 非常低 5.2.2.3 修复可行性评估 修复可行性评估首先需要根据上文风险处置的方式初步筛选出漏洞的处置方式，针对具体的修复方式（如补丁升级、版本升级、更换组件等）进行测试验证，评估对 OTA 系统是否造成影响或引入新的高危及以上风险。5.

181、2.2.4 测试验证 对已经修复的漏洞进行测试验证，如重新漏洞扫描、渗透测试、人工复现等进行验证。5.2.2.5 闭环 在测试验证阶段确认漏洞修复有效后，对相关风险评估和测试验证过程文档 75/136 进行归档保存，最后可流程闭环。5.3 OTA 网络安全风险分析 根据 OTA 威胁分析和风险评估流程，OTA 面临的网络安全风险包括 OTA平台安全风险、通信安全风险、车端安全风险和升级包安全风险。5.3.1 OTA 平台安全风险 OTA 平台安全风险主要包括云平台自身安全、第三方应用安全两个主要方面。（1）云平台自身安全风险 OTA 平台大多数部署在云端服务器中，会面临传统云平台的所有安全威胁

182、，包括网络威胁、主机威胁、应用威胁、数据威胁等。攻击者利用 Web 漏洞、数据库漏洞、接口 API 安全注入漏洞等手段发起 DDoS 攻击、MITC 攻击、跨云攻击、编排攻击、加密劫持等，可能导致 AccessKey 泄露风险、云上安全配置缺陷、用户敏感信息泄露、推送的升级包被篡改、升级策略更改等风险。（2）第三方应用安全风险 随着车载平台的发展，第三方应用也会随之增长，第三方应用的 OTA 也将会成为一个很重要的部分。升级后的第三方产品可能存在系统兼容性或者系统漏洞，甚至严重的 BUG，所以 OTA 平台也需要考虑到第三方应用的升级流程与规范要求。5.3.2 通信安全风险 OTA 通信安全风

183、险主要包括身份认证、传输加密、中间人攻击三个主要方面。（1）身份认证安全风险 身份认证风险体现在通信过程中未对通信对象进行有效身份验证，攻击者通过使用基站伪造、身份伪造、动态劫持等方式冒充合法参与者，参与车云通信，非法监听通信信息。例如，OTA 云服务推送软件升级包到车端的过程，若采用弱认证方式或明文传输，容易遭受中间人攻击、窃听攻击等。终端下载升级包的传 76/136 输流程中，如果终端在升级流程中同时缺少验证机制，那么被篡改的升级包即可顺利完成升级流程，达到篡改系统，植入后门等恶意程序的目的。攻击者还可能对升级包进行解包分析、篡改升级包信息等，或者获取一些可利用的信息，如漏洞补丁等，可能导

184、致关键信息泄露、代码业务逻辑泄露等风险。（2）传输过程安全风险 传输风险主要发生在车辆通信信息在未进行加密、加密强度较弱、密钥信息暴露等情况下，导致容易遭受恶意攻击，造成通信信息的泄漏、非法篡改和破坏。例如，云端与车端的通信过程若采用不安全的通信协议或通信过程不采用认证机制、明文通信等，容易遭受中间人攻击、窃听攻击、重放攻击、DoS 攻击等，可能导致车端升级信息错误、敏感信息泄露、拒绝服务等风险。（3）中间人攻击安全风险 中间人攻击体现在协议链路层通信未进行加密，攻击者可以通过抓取链路层标识实现会话劫持，攻击者可以基于中间人伪造协议而实施对升级包的篡改，窃取等。此外，在自动驾驶情况下，汽车使用

185、了篡改后的升级包，攻击者通过利用升级包中预植的木马，干扰车辆正常控制，带来交通安全风险。5.3.3 车端安全风险 车端安全风险主要包括版本回退、车端升级程序被破解绕过、拒绝更新三个主要方面。此外，车端系统出现公开漏洞，若不及时进行修复，可能导致黑客利用漏洞进行攻击，造成车辆、财产乃至人身安全风险。（2）版本回退风险 一般场景下的升级都是由低版本升级到高版本系统，但如果车端升级未对升级包版本进行判断，攻击者可以利用此漏洞，使用存在已知安全漏洞的低版本系统覆盖现有的系统，将导致车辆面临安全风险。（1）车端升级程序被破解绕过 按照 OTA 和安全相关的国际和国家标准要求，升级过程都需要在车辆端对升级

186、包进行加密和签名验证等一系列验证环节，经过验证的升级包才能进行正常的升级流程。如果验证的算法过于简单或者验证流程存在漏洞，攻击者可以利用 77/136 这些漏洞构造有效的升级包或者绕过验证流程，在部件上加载运行恶意篡改过的固件，对车辆进行进一步的攻击或者控制等恶意行为。（2）拒绝更新风险 在车辆升级过程中，攻击者可能会阻止车辆修复功能漏洞，通过控制车辆拒绝访问更新而无法解决车辆潜在漏洞或其他问题。常见的攻击方式包括：通过阻断或拦截外部或内部网络通信流量，阻止车端 ECU 接收任何更新。5.3.4 升级包安全风险 涉及升级包的应用场景分为升级包车云传输、升级包车内传输、升级包安装。三类应用场景中

187、，升级包安全风险主要包括升级包信息泄露、升级包信息篡改、升级包信息伪造三个主要方面。（1）OTA 升级包信息泄露风险 OTA 升级包的机密性破坏，攻击者可轻易捕获并分析通信数据，导致升级包信息泄露风险。（2）OTA 升级包信息篡改风险 OTA 升级包的完整性破坏，攻击者获取 OTA 通信数据并进行篡改，造成升级包被篡改或升级指令错误。（3）OTA 升级包信息伪造风险 车云之间失去身份的真实性，攻击者伪造非法信息进入平台或车辆，导致下发恶意升级指令或上传虚假信息等。（4）OTA 升级包代码安全风险 未对升级包进行代码检测，以及对代码所应用的第三方开源代码进行溯源和分析，导致升级包中存在缺陷（bu

188、g）。5.4 OTA 数据安全风险分析 汽车 OTA 带来对已售车型大量应用服务的数据井喷，还面临在保证用户个人信息安全的前提下，企业如何实施数据利用共享，OTA 相关数据如何跨境流通等问题。这些安全风险都对企业的合规管理与创新发展提出新的要求。78/136 5.4.1 用户隐私信息泄漏风险 汽车远程升级整个过程中涉及到云端服务器安全、车端安全、车云通信安全，也关系到生产者、用户及汽车软件供应商等其他主体之间的数据收集、数据传输等多个处理环节。在这些过程之中如果存在网络攻击风险，可能导致 OTA 系统遭受破坏，不法分子可以通过 OTA 系统窥探到用户的隐私信息，如车辆位置、行车路线等行为习惯。

189、同时，第三方应用平台可能存在非法获取其他应用和车载端数据的风险。5.4.2 数据出境合规风险 随着系列政策文件均提出汽车产生的个人信息和重要数据出境管理要求，智能网联汽车作为重点监管对象，产生的大量数据为数据跨境管理带来新的风险。对跨国企业而言，涉及技术研发的数据免不了出境或远程跨国访问，若分布于各国的数据只能本地存储而无法出境交互，将动摇跨国车企一直以来采取的开发、维护、集中化管理模式，导致车企需重新对一国市场进行单独资源调配，建立和总部一致的技术团队，成本不可估量18。因此在车辆售出后，面对远程升级需要的软件版本号、升级包名称、升级时间等决定功能实现的数据如何合法地出境流动仍然存在管理规定

190、不明晰带来的风险。5.5 OTA 功能安全风险分析 当涉及车辆核心功能如动力、制动和电池管理系统等模块的远程升级时，可能对车辆的功能安全带来新的挑战，升级后的系统将车辆与驾驶人暴露在未知的危险中。OTA 功能安全风险可举例为：5.5.1 车端升级条件判断不当导致的安全风险 车辆远程升级是一个比较长的过程，而且升级过程中车辆大部分功能可能无法正常使用，所以一般都要求车辆在 P 档、电池电量充足等一定条件下才能进行。如果车辆对于升级条件的判断存在问题，可能导致在非预想的情况下触发升级事件，对车辆和车内人员人身安全造成威胁。79/136 5.5.2 车端升级失败导致的车辆功能不可用 在车辆升级过程中

191、可能出现断电等异常情况导致升级失败的情况，如果没有对升级失败的情况进行妥善的容灾处理，可能导致车辆无法启动，甚至零部件损坏等严重事件。5.5.3 OTA 升级软件自身缺陷导致的风险 软件更新后未进行充分验证和测试就直接部署到车辆上，软件自身的缺陷可能会使软件运行出现意外行为，导致系统崩溃、触发车辆失控等安全事故。5.5.4 软件不兼容风险 在车辆升级过程中，升级软件可能引入新的功能和接口，如果车辆硬件不支持或不兼容，可能导致升级后系统无法正常工作，造成行车安全隐患。为应对上述 OTA 安全风险，总体来说，在云平台端可采用证书，签名和加密机制，负责为 OTA 服务平台提供安全服务，包括密钥证书管

192、理服务，数据加密服务，数字签名服务等，保证升级包不会随意被制作和发布，升级包的内容不会被恶意获取。在通信链路端，可通过可靠的物理链路和安全传输协议来保证网络传输安全。在车端，可通过汽车的功能域隔离，划分不同 ASIL 等级，通过冗余设计保证整车的功能可靠性；车辆终端 OTA 组件对升级包进行合法性验证，适配安全升级流程，通过安全启动来保证可信的软件在 ECU 上加载启动运行。80/136 第六章第六章 汽车远程升级汽车远程升级(OTA)测试评价研究测试评价研究 OTA 测试需要从标准合规测试、开发测试两个维度进行同步考量。其中合规测试需要满足 UN R156 和国标的相关要求；开发测试又可从功

193、能测试和安全测试两个细分维度进行展开，共同保障车辆从云端、通信链路端、车端三个层面的功能与安全的总体要求。在体验评价层面，侧重于合规评价和升级全过程评价，结合主观和客观的相关评价项，给予了车辆 OTA 相关指导性评价思路与方法。6.1 国内主要第三方测试机构概述（1）工业和信息化部计算机与微电子发展研究中心工业和信息化部计算机与微电子发展研究中心(中国软件评测中心中国软件评测中心)中国软件评测中心作为国家强制标准汽车软件升级通用技术要求制定的牵头单位之一，可依据标准检测 OTA 功能的正确性及信息安全防护的有效性。目前已开展多项汽车软件升级测试服务，覆盖国内外车企的电动汽车、燃油车和混合动力车

194、等不同车型。同时为 OEM 提供汽车软件升级的管理能力建设、功能合规建设、升级活动建设等方面的咨询服务。（2）襄阳达安汽车检测中心襄阳达安汽车检测中心 襄阳达安汽车检测中心可为 UN R155、UN R156 以及汽车软件升级通用技术要求的测试项提供标准符合性自动化测试服务。已形成覆盖“OTA 标准测试”“OTA 开发测试”“测试方案咨询”“SUMS 咨询服务”“信息安全服务”的汽车软件升级综合服务能力，可为企业提供 OTA 测试整体解决方案，帮助企业更好地完成备案工作。截至目前，达安中心已为多款车型进行 OTA 测试验证。（3）中汽研软件测评中心中汽研软件测评中心 中汽研汽车检验中心是国内首

195、批开展 UN R155 测评机构,首批具备 UN R156的 CNAS 资质的检测机构,2018 年以来,累计开展 40 余款车型的整车或零部件的安全测试。（4）上海机动车检测认证技术研究中心上海机动车检测认证技术研究中心 上海机动车检测认证技术研究中心在软件升级领域具有专业的测试设备、人员和经验，作为国内首批开展 GB汽车软件升级通用技术要求标准验证的检测机构，目前已完成 3 家车企的标准验证工作，可为企业提供台架级和整车级 81/136 OTA 测试验证和咨询服务。（5）招商局检测车辆技术研究院招商局检测车辆技术研究院 招商局检测车辆技术研究院由招商局集团和重庆市政府整合相关资源组建而成。

196、主要从事汽摩产品公告、CCC、道路运输车辆达标车型、环保型式认证等法规检测，研发验证、供应商检测、进口商检、出口认证、标准制修订、技术咨询等工作；建有汽车、摩托车、智能网联汽车 3 个“国家质检中心”，具备整车或零部件 OTA 测试能力。（6）中国汽车工程研究院）中国汽车工程研究院 中国汽车工程研究院具备支持整车企业完成 SUMS 建设、CSMS 建设的服务能力；具备 GB汽车软件升级通用技术要求、GB汽车整车信息安全技术要求 法规摸底测试能力；UN R155、UN R156 的车型测试检测能力已获得 CNAS授权；已为多家整车企业执行覆盖 OTA 软件升级正向开发的云管车端单件级、台架级及整

197、车级的功能测试。（7）国汽（北京）智能网联汽车研究院国汽（北京）智能网联汽车研究院 国汽（北京）智能网联汽车研究院电子电气信息架构实验室形成以车载以太网、SOA、OTA 刷写测试开发及测试服务为核心的专业技术能力。可面向行业内提供部件级、系统级、实车级 OTA 测试服务，同时可提供定制化测试方案、测试台架设计、自动化测试工具链集成开发等服务，已为多款车型进行 OTA 测试验证。6.2 OTA 标准合规测试 UN R156 法规于 2021 年 1 月正式生效，其对车辆制造商 OTA 管理能力和车辆型式认证均提出了准入管理要求。国标汽车软件升级通用技术要求（以下简称“国标”）目前也已经处于征求意

198、见阶段。UN R156 和国标对整车企业的软件升级管理体系（SUMS）建设和型式认证方面提出了具体要求。车辆型式认证主要从一般要求和在线升级附加要求两个方面展开，如图 6-1 所示。其中一般要求，规定了升级包真实性和完整性、软件识别码/软件版本的更新、读取以及防篡改要求。在线升级附加要求部分，可从升级前、升级中、升级后三个维度进行展开，其中升级前从用户告知、用户确认、先 82/136 决条件、电量保障四个层面开展测试；升级中从车辆安全、驾驶安全、车门防锁止三个层面开展测试；升级后从失败处理、用户告知两个层面开展测试。图图 6-1 车辆型式认证车辆型式认证 6.3 OTA 系统功能测试 目前，汽

199、车制造及迭代周期加快，汽车制造商会选择软硬解耦、硬件预埋方案，等待软件研发成功后再远程升级。因此前期的 OTA 测试就保证软件的真实性、完整性、可用性、访问可控性尤为重要。根据主机厂提供的 OTA 设计规范及相关技术文档，测试机构可基于 OTA 的架构设计、功能设计进行测试用例编制及测试环境准备，测试系统功能是否符合主机厂定义的需求规格说明书，核实系统功能是否完整，且没有冗余和遗漏的功能。OTA 系统功能测试主要分为各部件级、系统级和整车级功能测试，并在升级流程中完成对功能异常情况的测试覆盖，如图 6-2 所示19。部件级测试可拆分成OTA 平台测试、OTA 链路测试和 OTA 车端测试。具体

200、内容见附件 4 OTA 系统功能测试主要测试项。83/136 图图 6-2 OTA 系统功能系统功能测试流程图测试流程图 6.4 OTA 安全测试 6.4.1 安全测试概述 行业内对 OTA 的测试验证普遍侧重功能验证，对网络安全的测试验证关注度较低，可参考的相关测试方法和实践经验较少。相关行业标准法规如 UN R155/R156,以及 ISO/SAE 21434、ISO24089 中均提及了网络安全测试的要求，但并未说明具体的测试内容及方法。因此本节内容主要对 OTA 涉及的数据安全和网络安全测试进行研究，结合第五章的风险分析中所识别的安全风险，在参考其他相关行业现有的网络安全实践经验，并结

201、合目前主流 OEM 及相关评测机构的实践经验的同时，研究如何针对性地制定测试方案，以确保安全风险可被消除或有效缓解。6.4.1.1 安全测试方法 安全测试通过采用不同测试手段，检查系统的实现与安全功能规范定义的差异，发现可能被外部攻击者利用的实现错误，确保系统未识别的安全风险和漏洞 84/136 被控制在最小范围，从而保证系统的安全性。根据测试的阶段和目的不同以及ISO/SAE 21434 中对最小化未识别弱点和漏洞的要求，安全测试方法可以分为四个类型，即功能性网络安全测试、漏洞扫描、模糊测试和渗透测试。(1)功能性网络安全测试（functional testing）：功能性网络安全测试主要在

202、正确性、性能、法规遵从性和健壮性方面测试安全功能的实现情况。OTA 系统常见的安全功能包括身份验证和升级包的加密签名以及访问控制等。(2)漏洞扫描（vulnerability scanning）：漏洞扫描基于动态应用程序安全测试方法进行，通常由漏洞扫描工具格式化输入，以测试目标软件是否存在已知的常见安全漏洞。除了检测已知的漏洞外，还可以通过使用已知攻击模式进行漏洞扫描来检测目标软件中的未知漏洞。(3)模糊测试（fuzz testing）：通过向目标系统发送错误的输入来检查未知的、潜在的系统关键安全行为，以测试和发现未知漏洞。模糊测试通常包括 3 步：1)生成目标系统输入；2)将输入传递给目标系

203、统；3)监控目标系统以检测程序中的错误。(4)渗透测试(penetration testing)：在渗透测试过程中，测试人员从真实攻击者的视角，发掘并利用系统的漏洞，改变目标系统的行为以达到攻击目的。渗透测试可以在产品全生命周期帮助发现系统在早期开发测试阶段遗漏的问题，是创建安全产品的重要步骤。6.4.1.2 安全测试流程 根据 ISO/SAE 21434道路车辆-网络安全工程标准中车辆全生命周安全管理的相关要求，安全测试的流程可总结大致步骤如图 6-3 所示，包括系统项目定义、风险和威胁分析、安全概念定义、测试规划与场景定义、测试用例开发、安全测试执行、测试报告生成。85/136 图图 6-

204、3 车辆安全测试流程车辆安全测试流程 对于 OTA 系统而言，根据前面章节描述，系统包括 OTA 云平台、OTA 通信链路、车端 OTA 主控以及目标 ECU;风险和威胁分析可参考第五章的描述，已知的威胁和测试发现的漏洞均可作为分析依据；本节后续内容将从云、管、端分析安全测试场景及相关测试方法。6.4.2 云端安全测试 OTA 云端主要用于升级包管理、用户管理及任务管理等。OTA 云端服务与其它云平台一样，容易遭受黑客攻击，如暴力破解用户认证信息，数据库 SQL 注入攻击，拒绝服务攻击等，从而可能导致用户敏感信息泄露、推送的升级包被篡改、升级策略被更改或影响车端安全运行等风险。云端安全测试中包

205、括身份认证管理安全测试、数据及存储安全测试、OTA 平台渗透测试。6.4.2.1 身份认证管理测试 通常情况下，云端需要提供 API 接口供车端或第三方应用使用，在此之前，需要做身份认证，身份认证安全测试用于验证系统对用户认证信息安全防范的能 86/136 力，应包含：弱口令测试：测试系统是否未做弱口令限制；口令策略测试：测试系统是否存在强口令安全策略；认证绕过测试：测试是否可绕过系统认证；账号锁定测试：测试恶意请求（如频繁访问 API）是否会锁定账户。认证通过后，云端对不同身份及权限进行区分和管理时，也会存在一定的安全风险，如用户登录身份（令牌）过期安全，越权访问等；6.4.2.2 存储安全

206、测试 云端数据及存储安全测试主要包括以下几点：(1)数据访问安全测试：需要对云端的数据访问管理及安全防御系统进行测试，测试非法用户是否能够获取数据访问权限，测试不同的角色（用户）对不同的数据访问是否安全，特别对于云端数据管理相关角色，如果权限设置不当，会对 OTA 系统带来安全隐患。(2)数据隔离安全测试：OTA 云端服务通常需要对不同的数据进行管理，如OTA 安装包，用户相关数据，日志数据等，这些数据往往会在多个信息系统之间共享，数据隔离安全问题是云端环境中的重要安全问题，如果在各个系统共享数据的过程中，数据加密处理不当或数据存储、管理未做安全隔离，可能会因为某个系统的安全问题导致黑客获得整

207、个系统数据的机会，从而造成资源信息泄露。(3)数据存储安全测试：数据存储安全测试用于测试云端环境是否能够对数据进行安全管理。敏感数据存储安全，测试对于敏感数据是否进行加密存储。数据完整性安全，需要对用户提交的数据做合法性检查，防止不符合规范的数据进入系统，以确保数据的正确性、有效性和一致性。数据恢复安全，测试遇到数据错误时系统是否能够快速恢复，如是否有日志记录，是否对数据和系统文件进行定期备份；遇到灾难性错误还原不了错误的情况下，是否能够恢复到最近一次记录。6.4.2.3 OTA 平台渗透测试 87/136 对于 OTA 云端安全测试，除了身份认证管理安全和数据存储安全，还需要防范网络渗透测试

208、，攻击者通过对 OTA 平台进行渗透测试，可能获取云端的管理权限，使得攻击者可能对车辆使用者造成人身安全影响，如篡改平台给车端下发的指令，远程控制车端系统；另外，由于云端会存储大量用户信息、车端状态信息以及车辆数据，攻击者通过利用平台漏洞信息获取平台操作权限，可以窃取用户信息，造成个人隐私泄露风险。对于平台的渗透攻击，会涉及到所有与平台相连接的车辆、应用及与其相关的所有设备。OTA 平台渗透测试包含以下几方面：(1)平台扫描测试：对云端系统利用工具进行自动化扫描，如 IP 段扫描获取云端开放服务的 IP 信息，端口扫描获取系统开放的端口信息，操作系统探测扫描获取系统的操作系统信息，已知漏洞扫描

209、利用已知的漏洞数据库查看系统是否存在公开的漏洞。通过自动化扫描工具，可以发现系统配置，开放服务，系统网络配置的安全隐患，并及时发现系统是否有未修补的公开漏洞。但是此方法无法发现未知漏洞。对于未知的漏洞，可以借助如模糊测试的方法，对系统的接口进行漏洞挖掘，提前发现安全隐患。(2)缓冲区溢出测试：缓冲区溢出漏洞在渗透测试网络攻击中占较大比重，且危害巨大，因此针对缓冲区溢出攻击漏洞进行渗透测试是必不可少的。通常缓冲区溢出是由于云端系统接口的输入参数不合法造成的，通过向系统中程序的缓冲区写超出其长度的内容,造成缓冲区的溢出,从而破坏程序的堆栈,使程序转而执行其它指令,以达到攻击的目的。对于缓冲区溢出的

210、防范，除了开发阶段需要注意正确编码以外，云端服务可以考虑以下减缓措施：关闭云端不必要的端口或服务，并设置适当的防火墙出入站规则；及时更新云端依赖的第三方服务漏洞补丁；对于运行的服务或程序赋予最小权限。(3)SQL 注入测试测试：SQL 注入测试用于测试云端是否存在 SQL 注入安全漏洞，通常情况下云端服务程序会利用用户的查询参数进行数据库的 SQL 查询，如果没有做 SQL 注入安全检查，可能会让攻击者通过构造恶意的查询参数，获取到数据库的权限或非法的数据库操作，从而造成信息泄露或数据安全问题。(4)拒绝服务攻击测试：拒绝服务攻击（DoS）主要通过各种方式抢占和耗费云端的系统资源使系统过载或崩

211、溃，造成合法用户不能对网络带宽和服务器等 88/136 资源的合法访问。常见的攻击方式有 SYN Flood 攻击、IP 欺骗性攻击、UDP 洪水攻击。对于拒绝服务攻击而言，目前还没有比较完善的解决方案，但是即便如此，平台应考虑从攻击影响的角度做防范，攻击影响自低向高可以分为：无效（None）、服务降低（Degrade）、可自恢复的服务破坏（Self-recoverable）、可人工恢复的服务破坏（Manu-recoverable）以及不可恢复的服务破坏（Non-recoverable）。对于无效的攻击可以不做处理，对于服务降低的影响需要考虑系统的服务范围是否是非关键性的，如影响车辆安全。对于

212、可人工恢复的服务破坏，要考虑系统自动恢复的能力。对不可恢复的服务破坏，需要有紧急应对方案。6.4.3 通信安全测试 通信链路是车端与云端进行 OTA 更新通信交互的通道，也是导致车端对外暴露软件更新接口的主要路径，如果没有相应的安全保护措施，针对通信链路的攻击可能会造成更新信息泄露、非授权实体对车端或云端进行控制造成升级失败等风险。本小节将从协议安全、证书安全和加密传输三个方面讨论 OTA 通信安全测试。6.4.3.1 协议安全测试 在车辆与 OTA 平台进行通信过程中，应采用安全通信协议进行数据传输，以确保交互信息、软件升级包等数据的安全性，防止泄漏、篡改伪造等风险。通常情况下，采用基于 T

213、LS 的 HTTPS 安全协议，并且协议版本应为 1.2 及以上。车辆与 OTA 平台之间基于 TLS 1.2 协议实现数据传输示例如图 6-4 所示。HTTPS使用的 X.509 数字证书应由可信证书机构（Certificate Authority，CA）签发。这些证书用于验证车辆和 OTA 平台之间的身份和数据安全性。为了确保证书的可信性，建议使用受信任的第三方证书机构来发行和管理证书。可通过在车端设置代理网关，或者在车端或 OTA 云平台端操作系统中运行TCPdump、TShark 等命令，或者在网络中设置网络协议分析系统获取车端和 OTA云平台之间的网络通信流量。使用 wireshar

214、k 等软件查看数据包，验证其是否采用安全通信协议，如 SSL/TLS 协议和数字签名等，还可进一步通过修改通信数据，检查是否会触发安全机制，如数字签名验证失败或者无法连接到 OTA 平台 89/136 等。这些方法可以帮助我们更加细致地检测和评估车辆与 OTA 平台之间的通信安全性，确保数据传输的安全可靠。图图 6-4 车辆与车辆与 OTA 平台之间基于平台之间基于 TLS 1.2 协议实现数据传输（示例）协议实现数据传输（示例）6.4.3.2 安全证书测试 OTA 通信链路安全证书测试的开展，需要明确车端与云端实体及其通信相关信息、车端与云端实体安全通信的证书链、车端与云端实体安全通信的握手

215、过程三方面信息。安全证书测试所需明确的具体信息可参考以下 3 点的内容描述。(1)明确与车端通信的 OEM 或者第三方的云端后台及其通信内容，通信方式，通信频率。其中，通信内容包括并不限于软件升级包，用户语音数据，定位位置等个人信息，敏感个人信息和测绘数据等内容，这些内容都是车辆与 OTA平台之间通信的重要信息，需要采取有效的安全措施来保护这些信息的安全性和隐私性，参见表 6-1；通信方式包括车端直连云端后台或者通过 OEM 云端后台透传第三方云端后台等，在进行 OTA 通信链路安全证书测试时，需要明确这些通信方式的具体信息，以便更好地检测和评估车辆与 OTA 平台之间的通信安全性。参见图 6

216、-5；通信频率若为本地缓存方式，则上传本地缓存文件到云端后台，并上传文件成功后删除文件，若为无本地缓存方式，则直传 OEM 后台或第三方后台等。如果车端有多个云端，需要按照服务内容列出所有直连的云端后台。此外，车端与直连云端后台需要实施双向认证，车端证书只能由 OEM 授信的 CA机构签发。90/136 图图 6-5 车端车端直连直连或透传或透传的云端后台的云端后台 表表 6-1 车端与云端通信内容及方式车端与云端通信内容及方式 车端车端 通信通信 云端云端 车端应用名车端应用名称称 车端应用功能车端应用功能 通信数据通信数据（行踪轨迹，定位位置，个人信息等）（行踪轨迹，定位位置，个人信息等）

217、认证方式认证方式 Food Map Function A 定位位置 Access Token+TLS XXX后台 Function B 设备类型，设备 ID，定位位置 双向 TLS XXX后台 （2）明确车端以及车端直连云端后台的证书链，包括车端证书、OTA 平台证书等。这些证书是车辆与 OTA 平台之间安全通信的核心，可以帮助我们验证车端和云端实体之间的身份认证和数据安全性，参见图 6-6。图图 6-6 车端车端直连直连和透传云端后台及其证书链和透传云端后台及其证书链（3）明确车端与直连云端后台的握手过程，包括协商加密算法、交换数字证书、验证数字签名等，这些过程是车辆与 OTA 平台之间安全

218、通信的关键环节，91/136 可以帮助我们分析和检测可能存在的安全问题，如数据泄露、恶意篡改等，参见图 6-7。图图 6-7 车端与车端与直连直连云端后台握手过程云端后台握手过程 安全证书的测试包括物理测试和数据抓包测试。其中，安全证书物理测试包括并不限于检查车端证书是否完整，存放位置是否正确等；安全证书抓包测试，则通过使用 TCPdump、Wireshark 等工具进行通信数据包抓取，验证通信过程安全证书的使用情况。以下内容将分别针对证书安全物理测试和抓包测试方法进行说明。（1）安全证书物理测试：检查 OEM 签发的车端证书是否已经存放在车端；参考表 6-1 车端直连多个云端后台的情况，检查

219、是否所有车端对直连云端后台证书进行验证的远端后台证书对应的根证书都已经存放在车端；检查车端证书存放位置，是否是系统集成商指定存放位置；检查车端证书的基本信息是否正确，比如证书版本是否是 X.509 V3，证书有效期等字段是否与安全证书需求一致等。（2）安全证书抓包测试：请参考抓包工具相关使用说明在车端进行安装和配置；将车端应用拉起，并按照表 6-1 中列出车端应用功能的说明进行操作；将操作捕获的数据包在 Wireshark 中进行分析；通过数据包分析数据通讯过程中双向认证证书验证情况，例如，图 6-8 为车端对直连云端后台证书进行验证，图 6-9 为云端后台对车端证书进行验证。92/136 图

220、图 6-8 车端对车端对直连直连云端后台证书进行验证云端后台证书进行验证 图图 6-9 云端后台对车端证书进行验证云端后台对车端证书进行验证 6.4.3.3 加密传输测试 车辆与 OTA 平台通信过程中，应采用签名、加密、哈希等算法对数据的完整性和机密性进行保护，防止信息泄漏。通常采用 RSA、AES、SHA-256、SM2、SM3、SM4 等算法，同时应保证密钥长度满足一定安全性要求。基于 TLS 的HTTPS安全协议已经实现了加密传输，采用的密码算法有RSA、AES、SHA-256，也有使用我国商用密码算法 SM2、SM3、SM4 实现的 GMSSL，例如图 6-10、图6-11 所示。可

221、通过在车端设置代理网关，或者在车端或 OTA 云平台端操作系统中运行TCPdump、TShark 等命令供获取车端和 OTA 云平台之间的网络通信流量。使用wireshark 等软件查看数据包，验证是否存在明文传输的情况，并判断其采用的密码算法模式、密钥长度、哈希函数模式是否满足安全性要求。93/136 图图 6-10 车辆与车辆与 OTA 平台间基于平台间基于 TLS 1.2 安全通信协议实现数据加密传输安全通信协议实现数据加密传输 图图 6-11 经加密后的车辆与经加密后的车辆与 OTA 平台间通信数据平台间通信数据 6.4.4 车端安全测试 汽车 OTA 软件升级系统在提高软件升级效率的

222、同时引入了新的安全风险，诸如非授权软件安装，拒绝更新服务，以及获取升级包的逆向信息、log 敏感信息的保护等。车端升级主控以及目标 ECU 是 OTA 更新的执行对象，也是目标软件的执行主体，因此，车端安全测试验证是 OTA 验证链路最后一环也是重要一环。本小节针对这些风险从车端的角度分析相关测试验证方法，包括更新认证测试、ECU 安全访问的测试、ECU 安全启动测试、更新日志的安全测试以及升级包本身固件安全的分析测试。6.4.4.1 更新认证测试 软件升级包的身份验证，是目前防止恶意软件安装风险的主要应对措施。升级包的身份验证通常是通过数字签名实现的。如图 6-12 所示，目前 OTA 软件

223、升级包签名常见的做法是，供应商在交付软件前，通过 OTA 云平台对其进行数字签名，并附加到软件升级包中。在推送更新时，OTA 云平台对需要下发到车辆端的 OTA 升级包进行签名。车端主控在下载升级包后，对 OTA 包签名进行验证，而在执行安装时再由目标 ECU 对固件签名进行验证，从而实现对升级包的全链路认证。94/136 图图 6-12 升级包升级包的验证链路的验证链路 升级包认证测试的目的在于验证和确认具体给定的 OTA 更新系统在上一小节所描述签名验证链路各环节是否有实施并且有效验证升级包的真实性。根据OTA 更新业务流程及系统功能分布，结合系统安全风险分析情况，升级包测试认证可从供应商

224、、云端和车端 3 个方面开展。(1)供应商篡改更新数据：此测试场景目的在于验证 OTA 云平台是否有效校验供应商上传软件升级包的真实性，具体测试方法如下：供应商上传错误密钥签名的升级包或篡改合法签名升级包到 OTA 云平台，验证 OTA 云平台是否验证其签名有效性并拒绝上传请求。(2)云端篡改更新数据：此测试场景目的在于验证 OTA 主控是否有效校验云端或外部系统传输升级包的真实性，具体测试方法如下：1）OTA 云平台篡改签名密钥内容后使用错误签名密钥下发到车端 OTA 主控；2）验证车端主控是否在下载升级包且校验签名无效后放弃安装中断升级。(3)车端篡改更新数据：此测试场景目的在于验证目标

225、ECU 是否有能力验证升级包的真实性，具体测试方法如下：OTA 主控对下载校验通过的更新进行篡改，触发 OTA 主控使用篡改后的升级包安装到目标 ECU 上；验证目标 ECU是否检验到升级包签名无效而安装失败，从而阻止非授权软件的更新。6.4.4.2 访问控制测试 传统 ECU 通常通过统一诊断服务(UDS)对外提供诊断及软件更新功能。UDS通过安全访问服务(Security Access)提供内存写入保护以及关键功能的访问控制。95/136 一旦安全访问服务存在缺陷，则可能被攻击者获取访问关键受保护功能的权限，从而实现对 ECU 非授权控制或软件篡改。安全访问服务通过挑战-应答(Challe

226、nge-Response)的方式实现身份验证,关键流程如图 6-13 所示。图图 6-13 安全访问流程安全访问流程 OTA 主控或诊断设备通过诊断命令获取 ECU 生成的种子(即 Seed)，并通过约定的算法计算出对应的密钥(Key)值；诊断设备密钥发送给到 ECU，ECU 端通过与自身计算的密钥比对判断测试设备是否为授权设备。只有全访问验证通过ECU 才会执行后续对应安全访问等级要求的诊断请求。对 OTA 更新而言，在 ECU 端需要保护的主要资产是 ECU 的软件及相关配置、数据，主要安全属性是完整性。因此，对于安全访问服务威胁场景的测试，主要关注其是否对软件升级造成影响。(1)重放攻击

227、测试：针对此攻击场景，测试主要通过监控设备记录的种子-密钥对是否可解锁 ECU 从而对 ECU 软件进行刷写。主要测试方法为使用授权诊断工具或 OTA 主控对 ECU 重复多次进行安全访问服务操作，解析并记录种子-密钥对；判断种子是否使用固定值或者根据可推测的规律生成；在种子-密钥对记录中查找密钥并返回到 ECU，观察是否可成功获取安全访问权限。(2)暴力破解测试：此场景主要测试 ECU 是否采取防暴力破解措施(如限制重试次数)，以及 ECU 端措施是否会造成拒绝更新服务攻击效果。具体操作为根据 ECU 回复的种子，重复发送不同的随机密钥，尝试解锁安全访问；持续监控ECU 状况：是否顺利通过安

228、全访问验证，并更新成功；若多次尝试无法解锁 96/136 后，ECU 是否会拒绝 OTA 主控合法安全访问请求，造成无法更新软件。(3)中间人工攻击测试：此种攻击方式的测试不针对安全访问服务本身，而是验证在授权设备通过安全访问服务获取 ECU 刷写权限后，是否可以通过非授权设备对 ECU 进行软件刷写。主要操作为通过授权诊断设备或 OTA 主控对 ECU进行更新，在安全访问认证通过后，阻断授权设备与 ECU 通信；使用非授权设备对 ECU 进行非授权软件的刷写操作，验证是否成功刷写并运行非授权软件。6.4.4.3 安全启动测试 安全启动(Secure Boot)用于保证固件启动的代码受信任的安

229、全保证机制，它通过在引导加载过程中，对加载固件进行检验，从而防止加载和执行恶意代码。固件的每一步加载都经过数字签名认证，而每一步签名认证的根证书中的密钥需要与固化在芯片 CPU 内部不可修改(如 eFUSE)的签名密钥匹配，从而行成一个完整信任链。在系统上启用安全启动功能时，将不允许任何执行不受信任程序的尝试。安全启动验证简化流程如图 6-14 所示，ECU 通电时首先执行 CPU 内部只读存储(bootROM)的指令,bootROM运行后从一阶BootLoader(FBL-First stage BootLoader)镜像中获取其签名及根证书，通过根证书密钥与 eFUSE 中密钥匹配获得跟信

230、任后，校验签名加载一阶 BootLoader。随后依次逐级校验并加载各级程序，完成信任链的构建。图图 6-14 Secure boot 启动验证流程启动验证流程 安全启动的测试验证目的在于确认该功能各阶段加载不同程序前的安全校验及加载运行效果，主要分为正向功能测试和异常测试。(1)正向功能验证：此场景主要验证安全启动功能启用后，系统加载运行的情况：启用安全启动，验证是否可以使用正确签名镜像进行更新，并且可以加载 97/136 运行。(2)FBL 验证测试：此测试场景的目的是验证 FBL 在加载前会被有效地校验，主要测试方法为使用未签名或错误签名的 FBL 进行更新，验证安全启动功能是否成功阻止

231、其加载。(3)SBL 验证测试：此测试场景的目的是验证 SBL 在加载前会被有效地校验，主要测试方法如下：1)移除 FBL,尝试直接启动 SBL,验证未经校验的 SBL 是否被安全启动功能阻止加载；2)使用未签名或错误签名的 SBL 进行更新，验证安全启动功能是否成功阻止其加载。(4)安全 OS 验证测试：此测试场景的目的是验证安全 OS 在加载前会被有效地校验，主要测试方法为使用未签名或错误签名的 OS 进行更新，验证安全启动功能是否成功阻止其加载。(5)安全 APP 验证测试：此测试场景的目的是验证安全 APP 在加载前会被有效地校验，主要测试方法为使用未签名或错误签名的 APP 进行更新

232、，验证安全启动功能是否成功阻止其加载。6.4.4.4 日志安全测试 日志的功能是追踪，任何可能危害系统安全的操作都应被记录，测试时需确认是否以安全的方式记录了应该记录的信息。对于车端日志安全，需要测试以下几方面：(1)日志权限安全：通过多途径网络攻击的方式，是否能够获得日志权限，测试无权限情况下是否可查看日志，是否可以关闭日志权限。(2)日志系统是否正常开启：测试数据库，系统访问，系统操作日志是否正常开启。(3)网络攻击记录：测试日志中是否保存网络漏洞攻击、恶意爬虫扫描、异常访问等行为日志。(4)敏感信息测试：测试日志中是否存在敏感信息，如用户身份信息，车端权限信息，服务器信息等。6.4.4.

233、5 固件安全测试 98/136 OTA 升级包中通常包含多个固件升级程序，目前固件程序的安全性并没有得到足够的重视，已知的多种漏洞都是比较低级的错误，如弱身份认证、不安全的缺省配置、硬编码凭证或未经身份验证的管理接口等。这一类型的漏洞可以通过静态扫描提前规避，也可以通过增强厂商和消费者用户的安全意识进行缓解。但是由编程错误导致的内存破坏仍然需要有足够的重视，可以使用传统的一些表现良好的针对内存型破坏的软件测试技术，比如模糊测试或符号执行等。对于已知漏洞检测主要基于第三方库、已知固件中存在的漏洞，采用相似度检测或二进制关联算法查找新的设备固件中是否存在该漏洞。后门漏洞在于查找固件中存在的弱口令、

234、硬编码以及认证绕过等不安全的配置选项。0-day 漏洞是关注最多的，目的在于发现固件中的未知漏洞，包括 web 型和内存型。分析发现，静态分析技术仍然是业界进行固件安全性分析的主流技术，也是目前适用性最强的一类方法，但由于静态分析误报率较高，效率较低，因此需要动态分析技术进行弥补。6.4.4.6 硬件安全测试 对于硬件设备的 OTA 升级，尤其是涉及到安全性的升级，需要进行严格的硬件安全测试，以确保升级过程和结果不会引入安全漏洞或风险。（1）PCB 分析：PCB 分析的主要目的是评估硬件的安全性，包括物理安全、身份验证、固件安全和供应链安全等方面。通过模拟攻击和物理访问，识别和修复可能存在的硬

235、件漏洞和安全问题。（2）硬件调试接口测试：硬件调试接口测试旨在发现是否有隐蔽接口或后门，以及确定是否存在未经授权的访问或控制硬件接口的风险。通过硬件调试接口测试，可以评估设备在物理层面的安全性，从而帮助提高设备的整体安全性，减少潜在的物理攻击和未经授权的访问可能性。（3）固件提取测试：固件提取测试旨在评估设备的固件安全性，并发现可能被攻击者利用的漏洞。通过固件提取测试，可以获取有关设备内部运行和配置的详细信息，从而帮助提高设备的安全性，并减少潜在的风险和安全漏洞。（4）故障注入测试：故障注入测试是一种验证车辆远程升级系统是否能够有效处理异常情况和故障的测试方法。这种测试旨在模拟各种潜在的故障情

236、况，以 99/136 确保车辆在升级过程中能够安全地应对这些情况。6.4.5 功能安全测试 为了保证软件升级后的可靠性与安全性，应在未来考虑增加功能安全测试相关内容。6.4.5.1 升级包静态分析和审查 依据 ISO 26262 和 GB/T 34590 标准，对升级包进行静态分析，确保升级包代码的规范性、安全性，静态分析应包含但不限于以下内容：(1)明确所采用的静态分析方法：如控制流分析、数据流分析、结构覆盖分析等。(2)使用的分析工具：需要报告所使用的具体工具名称及其版本，同时给出工具自身正确性验证的结果。(3)代码扫描范围：需要明确静态分析的代码范围，即对升级包的哪些部分源代码进行了扫描

237、分析。(4)设置的规则和阈值：应明确配置的检查规则、风险级别的界定阈值等，以用来定义发现的缺陷类型。(5)扫描结果总结：需要总结和统计发现的代码缺陷数量、风险级别分布、缺陷类型分布等，确定最终缺陷结果。6.4.5.2 升级包接口测试 通过接口测试等测试方法，验证升级包接口设计的规范性和实现的一致性，接口测试应包含但不限于以下内容：(1)内部接口测试：对 OTA 升级后系统内部的通信和交互接口进行测试。(2)外部接口测试：对 OTA 升级后系统与外部的通信和交互接口进行测试。(3)接口功能测试：测试 OTA 升级后系统接口功能的一致性和正确性。(4)接口异常测试：测试接口的故障检测机制与容错恢复

238、功能。(5)安全机制测试：验证接口安全机制的正确性和有效性。6.4.5.3 基于需求的测试 100/136 通过基于需求的测试等测试方法验证 OTA 后的功能、性能和预期一致、功能可靠且不存在安全风险，基于需求的测试应包含但不限于以下内容：(1)功能需求测试：对 OTA 升级包功能、OTA 升级后系统的功能进行测试，验证功能的一致性和正确性。(2)性能需求测试：测试 OTA 升级后的系统性能指标。(3)安全需求测试：验证 OTA 升级后系统的故障诊断能力、容错能力和恢复能力。6.4.5.4 故障注入测试 通过故障注入测试验证 OTA 后整车安全目标是否违反、安全措施或安全机制的有效性、面对故障

239、和失效的容错能力与恢复能力。故障注入测试应包含但不限于以下内容：(1)通信网络故障：模拟网络延迟、断网等通信故障情况，测试 OTA 升级后系统响应行为。(2)数据错误故障：修改数据引入错误数据，检查 OTA 后系统的校验机制与容错处理。(3)版本识别故障：通过修改版本号或配置文件的方式使系统误判软件版本，验证兼容性机制的健壮性。(4)空间溢出故障：模拟存储空间占满，无法完成完整 OTA 升级，并检查后续的清空和恢复机制。6.5 OTA 体验评价 此前因为 OTA 技术服务不规范，给消费者造成很大困扰。目前相应法律法规强标均已出台，虽然都强调汽车生产企业是软件升级活动安全的责任主体，并规定消费者

240、需要对软件升级活动拥有知情权，但现行法规标准中缺少以消费者为中心的 OTA 技术服务体验评价指标。因此可配套软件升级全流程，将 OTA 体验评价分为主观、客观两个角度，对软件升级流程中是否提供给用户更多选择权、车辆控制权，用户培训及服务质量等评价指标进行规定。相关指导性评价思路与方法见附件 5 OTA 体验评价主要测试项。101/136 第七章第七章 汽车远程升级（汽车远程升级（OTA）发展建议）发展建议 7.1 加强政策引导，完善监管机制 一是加强政策宣贯引导一是加强政策宣贯引导。近年来，行业主管部门陆续出台关于加强智能网联汽车生产企业及产品准入管理的意见、关于进一步加强汽车远程升级（OTA

241、）技术召回监管的通知、关于开展汽车软件在线升级备案的通知等政策文件，汽车远程升级初步形成了以“事前备案”为主要手段的监管模式，明确了合法合规性、标准符合性、生产一致性等备案要求，因此，应进一步加强政策文件的解读宣贯工作，充分发挥政策引导作用，积极推动企业贯彻落实，督促企业落实备案主体责任，建立规范化、数字化的汽车软件升级管理体系。二是细化安全合规要求二是细化安全合规要求。对于企业来说，远程升级赋予了汽车产品新的生命力，为企业技术创新带来了更多的可能性，巧妙解决了汽车产品迭代与满足市场需求间的矛盾，与此同时，也为企业落实功能安全、网络安全、数据安全和个人信息保护带来了更多的挑战。从长远的角度来看

242、，仅仅依赖于“事前备案”机制是远远不够的，应进一步细化汽车远程升级的合规要求，聚焦功能安全、网络安全、数据安全、个人信息保护等重点领域，建立健全准入管理、测试评估、备案管理、状态监测、召回管理等监管环节，形成完整闭环。三是探索创新监管模式。三是探索创新监管模式。软件是汽车智能化、网联化发展的核心动力，是实现自动驾驶、智能座舱等功能的重要基础，随着汽车软件的快速发展，远程升级的范围将不断扩大，未来可能出现更灵活的远程升级模式。尤其在座舱领域，车机移动应用（APP）将更加多样化，用户可以像在手机应用市场一样自主升级车机应用，软件升级迭代频率更高，用户体验进一步提升，而且对汽车的一致性和安全性影响较

243、小。这种情况下，软件更新的频率、内容将更加依赖于软件开发商和应用市场运营商，以整车厂商“事前备案”为主的监管模式将难以适用，这就需要软件、信息服务、汽车等相关主管部门倾力协作，分类分级管理，既要加强汽车远程升级的“事中事后监管”，也要加强汽车软件研发运营的“源头监管”，形成工作合力，建立信息共享机制，切实推动汽车产业和软件产业的融合发展。四是开展安全监管四是开展安全监管活动活动。建设行业 OTA 运营安全监管体系，在降低车企建设成本的同时，形成统一的密码服务支撑体系。充分发挥我国汽车安全沙盒监管 102/136 制度优势，联合整车厂商、平台企业、科研院所、行业协会等单位，共同开展汽车远程升级安

244、全监管试点示范工作，及时将 OTA 技术引发的安全问题纳入监管范围，防范化解潜在安全风险，保护消费者合法权益，同时鼓励企业勇于技术创新，总结汽车安全实践经验。7.2 强化标准引领，规范行业发展 一是加快标准体系建设。一是加快标准体系建设。根据工信部发布的 2022 年汽车标准化工作要点，汽车远程升级是智能网联汽车标准化建设的重要内容，通过发布标准、试行验证、管理试点等方式，迅速形成行业规范，助力产业转型升级。在标准体系构建过程中，应加强汽车、通信、电子、道路交通、运输等领域标准的统筹设计、系统布局、有效衔接，充分考虑互联互通、技术兼容等实际需求，按需开展跨标准组织、跨行业标准联合研制，避免标准

245、要求片面、交叉、冲突。与此同时，应积极推动相关标准的试行验证、测试评估工作，在制定网络安全、软件质量安全相关标准时，应同步制定测试方法，依托重点实验室、质检中心、创新中心等构建测试验证实验室，评估实际应用影响，为构建汽车软件生态提供重要保障。二是强化接口标准研制。二是强化接口标准研制。当前，汽车电子电气架构逐渐由传统分布式架构转变为集中化架构，为实现“软件定义汽车”提供了重要的硬件基础，汽车软硬件逐渐呈现“解耦”趋势，软件架构更是由传统的“面向信号”转变为“面向服务”的 SOA架构，汽车软件开发正逐渐规范化、通用化、平台化，因此，汽车接口标准化建设刻不容缓。汽车接口标准化能有效减小待升级部件及

246、周边部件适配开发、联调、测试的工作量，是汽车“软硬件解耦”的重要环节，能大幅提升汽车远程升级的效率。此外，通过硬件接口、软件接口的标准化，有利于行业形成模块化、标准化的远程升级研发模式，缩短远程升级方案的设计、实施周期，通过灵活多变的模块组合能满足更多的场景需求，通过标准化的接口定义引入丰富的第三方应用程序资源，将切实推动汽车产业和软件产业的融合创新发展。三是充分发挥行业学会三是充分发挥行业学会/协会协会/联盟团标跨行业协同创新作用。联盟团标跨行业协同创新作用。实现市场主导的团体标准与政府主导的国家标准、行业标准优势互补和协调，发挥市场在标准化资源配置中的决定性作用。统筹利用汽车、信息通信、电

247、子、交通、公安、网信等相关行业优势资源，聚焦前瞻、交叉空白领域如软件接口、软件产品缺陷管 103/136 理、软件升级影响评估等技术标准研究，扩大先进适用团体标准供给，促进产品技术水平和质量提升。7.3 重视流程管理，形成完善体系 一是加强企业流程管理一是加强企业流程管理。在汽车远程升级管理方面，为了保证升级活动的有序开展，汽车生产企业应制定完善的软件管理流程，包括众多业务部门在各个环节中所承担的职责、实施细则和交付要求。为保证软件研发的质量和安全性，还应建立规范的软件开发流程，例如遵循 ASPICE 或者 CMMI 的模型框架来构建软件成熟度等级。此外，为了及时发现汽车远程升级过程中的问题，

248、减少软件更新发布后的风险，汽车生产企业应逐步构建测试验证平台和测评指标体系，包括开发过程中的部件级、系统级别以及整车级测试，同时，可以借助自动化手段提升测试效率，构建“云、管、端”一体化的全链路测试验证流程。二是落实合规运营管理。二是落实合规运营管理。在汽车远程升级运营管理方面，除了充分考虑用户体验和业务模式之外，企业还应重点考虑汽车远程升级所涉及到合规要求。首先，系统设计阶段应充分考虑汽车远程升级相关国家标准中的技术要求，形成规范化的解决方案；其次，软件升级管理体系的构建需要标准法规、网络安全、汽车研发等部门的参与，对于具有产品生产一致性要求的控制器软件要在车辆远程升级方案设计阶段就要识别出

249、来，并将一致性的评审纳入到远程升级迭代环节中；最后，企业应将汽车远程升级视为一个基础性产品，设置专门的产品工程师来梳理软件升级需求、不同车型软件升级实现的差异以及软件升级相关合规要求，及时针对远程升级实施过程中存在的方案设计、业务流程、合法合规等问题进行分析和解决。7.4 推进协同创新，构建良好生态 一是鼓励企业技术创新。一是鼓励企业技术创新。随着智能化、网联化程度不断加深，汽车成为移动智能终端已经是必然趋势，车载软件的开发模式正逐渐向移动互联网靠拢，汽车生产企业的研发体系面临着功能定义、迭代的考验。目前，远程升级的对象主要是汽车零部件，升级内容主要为软件和固件。随着汽车远程升级内容范围不断扩

250、大，行业亟需整车级的远程升级解决方案来实现更复杂的汽车功能升级，企业应 104/136 加大研发投入、勇于技术创新，不断外延汽车远程升级覆盖范围，更好的服务消费者。二是重视网络安全保障。二是重视网络安全保障。随着网络安全保障水平日益成为衡量汽车质量的重要维度，汽车产业链需重新思考网络安全在整个价值链中的重要作用，协同开展全生命周期安全风险管理全新实践，包括在设计阶段针对潜在安全风险开展系统评估、加强风险防范设计，在生产阶段从严供应链安全管理、实施关键软硬件和整车安全检测，在运行阶段实时监测安全风险、规范数据共享利用，发现安全漏洞缺陷后协同修补处置等。三是促进产业融合发展。三是促进产业融合发展。

251、汽车远程升级横跨汽车、软件、安全等多个产业，是产业融合创新发展的体现，但是，汽车生产企业、解决方案提供商、软件开发商、安全企业等仍未形成发展合力，汽车软件升级仍处于较为分散的状态。应充分发挥各个行业的自身优势，迅速整合行业优质资源，聚焦实际应用场景、顺应未来发展趋势，在汽车远程升级关键共性技术方面开展联合攻关，在业务流程、接口定义、安全合规等方面达成共识，促进汽车远程升级产业持续健康发展。105/136 参考文献参考文献 1.中国汽车工程研究院股份有限公司、车联网安全联合实验室.智能网联汽车网络安全与数据安全发展报告(2022 年)M.北京:社会科学文献出版社.2020.2.SOLWIT.R1

252、55/R156-a quick guide to the updated cybersecurity regulations for automotiveEB/OL.https:/ COMMISSION.COMMISSION DELEGATED REGULATION(EU)/.of XXX amending Annexes I,II,IV and V to Regulation(EU)2018/858 of the European Parliament and of the Council as regards the technical requirements for vehicles

253、produced in unlimited series,vehicles produced in small series,fully automated vehicles produced in small series and special purpose vehicles,and as regards software updateR.2022.4.Michael L.Sena.Secure Over the Air Vehicle Software Updates Operational and Functional RequirementsR.2015.5.TESLARATI.T

254、eslas software fixes,the NHTSAs status quo,and an impending need for updated recall terminologiesEB/OL.https:/ News Europe.Jeep hacking prompts Fiat Chrysler software update to enhance securityEB/OL.https:/ 7.Emma Himes,NHTSA Up in the Clouds:The Formal Recall Process&Over-the-Air Software UpdatesJ.

255、,Michigan Technology Law Review.2021(153).8.CNBC.Tesla shares fall after U.S.regulators launch formal investigation into Autopilot systemEB/OL.https:/ 9.CNBC.NHTSA asks Tesla why it didnt initiate a recall when it pushed safety-related software updateEB/OL.https:/ 106/136 10.CATARC 检测认证事业部.日本汽车市场准入制

256、度简介EB/OL.https:/www.auto- 11.SONDERHOFF EINSEL.Q&A ON the amended road transportation vehicle act introduction of vehicle software update regulationEB/OL.https:/ OTA 升级安全EB/OL.https:/ 13.汽标委智能网联汽车分标委.智能网联汽车新型电子电气架构标准化需求研究R.2022.14.产品安全与召回.OTA 升级是否计入三包维修等汽车三包典型案例分析EB/OL.https:/ 15.永安 华为.智能汽车云服务白皮书R.2

257、022.16.赵爽,谢玮.车联网网络安全风险和应对思考J.中国信息安全,2021(07):38-41.17.FIRST.Common Vulnerability Scoring System v3.0:User GuideR.18.21 世纪经济报道.智能网联汽车数据合规：数据跨境成监管重点，跨国车企迎挑战EB/OL.https:/ 19.高斐,杨诚潇.汽车整车远程升级(OTA)系统的发展 J.重型汽车,2022(5):33-34.20.SAE International.Proposal to Update the Interpretation Document for UN R156 Re

258、garding newly Available International Standard on Software Update Engineering for Road VehiclesR.2023.21.国家市场监督管理总局缺陷产品管理中心.缺陷产品召回查询EB/OL.https:/ 107/136 附件附件 1:UN R156 与与 ISO 24089:2023 的映射关系的映射关系20 UN R156 ISO 24089：2023 对应条款对应条款 映射程度映射程度 7.1.车辆制造商的软件升级管理体系要求-7.1.1.初步评估时要验证的过程-7.1.1.1.记录与本法规相关的信息并

259、由车辆制造商安全保存，可应要求提供给认证机构或其技术服务部门的过程；4.3.4.1 4.3.4.5 部分 7.1.1.2.可唯一识别所有初始的和升级的软件版本信息（包括完整性验证数据和型式认证系统的相关硬件组件）的过程；4.3.4.4 6.3.2.1 6.3.2.3 部分 7.1.1.3.可访问和升级车型 RXSWIN 在升级前后相关信息的过程。这应包括更新每个RXSWIN 所有相关软件版本及其完整性验证数据的能力；-未包含 7.1.1.4.对于具有 RXSWIN 的车型，车辆制造商可验证型式认证体系组件上的软件版本与相关RXSWIN 的定义版本一致性的过程；-未包含 7.1.1.5.可识别升

260、级系统与其他系统的任何相关性的过程；8.3.3.3 9.3.1.9 包含 7.1.1.6.车辆制造商能够识别软件升级的目标车辆的过程；8.3.1.1 9.3.2.1 9.3.2.2 包含 7.1.1.7.在发布软件升级之前，确认软件升级与目标车辆配置兼容性的过程。包括在发布升级之前，评估目标车辆最后已知软件/硬件配置与升级的兼容性；8.3.1.2 8.3.1.3 8.3.3.2 9.3.2.8 包含 7.1.1.8.评估、识别和记录软件升级是否会影响任何型式认证系统的过程。该过程应考虑软件升级是否会影响或更改、用于定义该升级可能影响的系统的任意参数，或者是否可能更改用于系统型式认证的任意参数（

261、如相关法规中所定义）；-未包含 7.1.1.9.车辆通过型式认证时，用于评估、识别和记录软件升级是否会增加、更改或启用任何不存在或启用的功能，或更改或禁用法规定义的任何其他参数或功能的过程。评估应包括以下方面的考虑：(a)信息包中将需要被修改的内容条目；(b)测试结果不再覆盖改装后的车辆；(c)对车辆功能的任何修改都将影响车辆的型式认证。-未包含 108/136 UN R156 ISO 24089：2023 对应条款对应条款 映射程度映射程度 7.1.1.10.评估、识别和记录软件升级是否会影响车辆安全持续运行所需的任何其他系统，或升级是否会增加或改变车辆登记时的功能的过程；4.3.1.2 8

262、.3.3.3 9.3.1.9 包含（除了车辆登记相关要求）7.1.1.11.通知车辆用户升级的过程。6.3.3.1 9.3.1.14 9.3.2.9 9.3.2.10 包含 7.1.1.12.车辆制造商应能根据第 7.1.2.3 和7.1.2.4 将信息提供给负责机构或技术服务部门的过程。这可能是出于型式认证、生产一致性、市场监督、召回和定期技术检查（PTI）的目的。-不包含 7.1.2.车辆制造商应记录并存储以下适用于给定车型每次升级的信息：工作产品已覆盖记录/存储/文档 7.1.2.1.描述车辆制造商进行软件更新时使用的过程以及用于证明其符合性的任何相关标准的文件；4.3.1.2（见工作产

263、品 4.4.1）包含 7.1.2.2.描述更新前后任何相关型式认证系统配置的文件，这应包括型式认证系统硬件和软件（包括软件版本）的唯一标识以及任何相关车辆或系统参数；4.3.4.4（见工作产品 4.4.1）5.3.1.2（见工作产品 4.4.1）部分包含 7.1.2.3.每个 RXSWIN 应有一个可审计的记录描述在车型升级前后软件版本管理相关的所有软件。每个软件版本管理需包括所有相关软件的软件版本信息和完整性验证数据。8.3.2.3 部分包含 7.1.2.4.列出目标更新车辆的文件列表，并确认目标车辆最后已知配置和更新的兼容性 4.3.4.4（见工作产品 4.4.1）8.3.3.2 8.3.

264、1.1（见工作产品 8.4.1 和8.4.3）9.3.2.2（见工作产品 9.4.2）包含 7.1.2.5.描述该车型所有软件更新的文档：(a)更新的目的；9.3.1.1（见工作产品 9.4.1）包含(b)更新可能影响车辆的哪些系统或功能；8.3.1.1 8.3.1.3 8.3.1.4 包含(c)其中哪些已获得型式认证（如有）；-不包含(d)在适用情况下，软件更新是否影响型式认证系统对任何相关要求的符合性；-不包含(e)软件更新是否影响系统型式认证的任何参数；-不包含(f)是否向认证机构寻求更新批准；-不包含(g)如何执行更新以及在什么条件下执行更新；工作产品 8.4.1 工作产品 9.4.1

265、 包含 109/136 UN R156 ISO 24089：2023 对应条款对应条款 映射程度映射程度(h)确认软件更新将安全可靠地进行；7.3.4.9 7.3.4.10（见工作产品 7.4.4）见工作产品 9.4.1 包含(i)确认软件更新已经进行并成功通过验证和确认程序。8.3.3.1 8.3.4.1（见工作产品 8.4.3 和8.4.4）包含 7.1.3.安全性车辆制造商应提供证明：7.1.3.1.确保有用于保护软件更新在更新开始之前被篡改的流程；4.3.1.3 5.3.4.1 6.3.1.1 7.3.1.1 7.3.1.2 7.3.1.3 7.3.4.6 7.3.4.7 8.3.4.

266、1 9.3.2.7 包含 7.1.3.2.升级流程应得到得到保护，从而合理的防止其受到损害，这包括了升级推送系统的开发过程；4.3.1.3 6.3.1.1 7.3.1.1 7.3.1.2 9.3.1.11 包含 7.1.3.3.该流程用于验证和确认车辆所使用的软件功能和软件代码是否适当。-不包含 7.1.4.空中软件更新的附加要求 7.1.4.1.如果升级是在驾驶过程中进行，车辆制造商应证明，会采用流程和程序评估空中升级不会影响安全。7.3.1.2（特附示例）7.3.4.9（特附示例 3 和 4）8.3.1.6（特附示例）包含 7.1.4.2.车辆制造商应证明使用了流程和程序来确保在空中升级需

267、要特定的技能或复杂操作（例如重新校准传感器后编程）时，为了完成升级过程，只有在具备技能完成这些操作的人员在场或流程可控的情况下才能进行升级。7.3.1.1（特附示例 1）8.3.1.8 8.3.3.8 9.3.1.12（特附示例 1）9.3.2.13 包含 7.2.车型要求 7.2.1.软件更新包要求 7.2.1.1.软件更新包的真实性和完整性应受到保护，以合理的方式防止软件包被破坏并阻止无效的更新。5.3.4.1 7.3.4.6 7.3.4.7 9.3.2.7 包含 7.2.1.2.针对具有 RXSWIN 的车型：7.2.1.2.1.每个 RXSWIN 应是唯一可识别的。如果车辆制造商修改了

268、与型式认证相关软件时导致型式认证扩展或需要进行新的型式认证时，-不包含 110/136 UN R156 ISO 24089：2023 对应条款对应条款 映射程度映射程度 则应更新 RXSWIN。7.2.1.2.2 每个RXSWIN应易于通过电子通信接口进行标准化读取，至少采用标准接口（OBD端口）。尽管不在范围之内，但以下要求可实现该功能：7.3.2.1 部分包含/不包含 如果车辆没有 RXSWIN，制造商应向型式认证许可机构声明与型式认证相关的车辆的软件版本集或单个 ECU 的软件版本。每次更新声明的软件版本时，都应更新该声明。在这种情况下，软件版本集应易于通过电子通信接口进行标准读取，至少

269、通过标准接口（OBD 端口）。-不包含 7.2.1.2.3.车辆制造商应防止未经授权修改车辆上的 RXSWIN 和/或软件版本集。进行型式认证时，车辆制造商对所采用的防止的未经授权修改车辆 RXSWIN 和/或软件版本的方法应采用机密方式提供。尽管不在范围之内，但以下要求可实现该功能：5.3.4.1，特附第四点 7.3.1.3，特附 NOTE 2 7.3.2.2 部分包含/不包含 7.2.2.OTA软件更新的附加要求 7.2.2.1.如车辆具备软件更新功能，则应具有以下功能：7.2.2.1.1.车辆制造商应确保在更新失败或中断时，车辆能够将系统恢复到前一版本，或在更新失败或中断后，车辆能够进入

270、安全状态。6.3.4.7 7.3.4.10 8.3.3.5 9.3.1.10 9.3.2.14 包含 7.2.2.1.2.车辆制造商应确保只有在车辆有足够的电力完成更新过程时，软件升级包才能被执行。（包括可能恢复到之前版本或使车辆处于安全状态）7.3.4.3（特附示例）8.3.1.5 8.3.3.4 9.3.2.5 包含 7.2.2.1.3.当执行升级可能影响车辆安全时，车辆制造商应证明如何安全地执行升级。应该采用技术手段确保车辆处于安全状态下执行升级。7.3.4.9 8.3.1.2（特附示例 1）8.3.1.8（特附 NOTE）8.3.3.8 9.3.2.5 包含 7.2.2.2.车辆制造商

271、应证明在升级执行之前，车辆用户能够得到升级通知。提供的信息应包含：6.3.3.1 9.3.2.10 9.3.2.12 包含(a)升级的目的。可能包括升级的重要性，以及升级是否出于召回、安全（功能安全和/或网络安全）的目的；9.3.1.1 9.3.2.10（特附第一点）包含(b)关于车辆功能的升级带来的任何变更；9.3.1.1 9.3.2.10（特附第四点）包含(c)升级完成的预估时间；9.3.2.10（特附第六点）包含(d)在执行升级期间，可能不可用的所用车辆功能；9.3.2.10（特附第五点）包含 111/136 UN R156 ISO 24089：2023 对应条款对应条款 映射程度映射程

272、度(e)可能帮助车辆用户安全地执行升级的所有指导；9.3.2.10（特附第三点）包含 一组更新包具有相同内容，可以用一个信息覆盖整组更新包。7.3.3.2（特附 NOTE 1）包含 7.2.2.3.驾驶过程中执行更新可能不安全的情况下，车辆制造商应证明他们将如何：7.3.1.2 7.3.4.9 8.3.1.5（特附示例）8.3.1.8 8.3.3.8 包含(a)确保升级执行期间无法驾驶车辆；7.3.1.2（特附示例）7.3.4.9（特附示例 4）8.3.1.5（特附示例）包含(b)确保驾驶员无法使用任何可能影响车辆安全或更新成功执行的车辆功能。7.3.1.2（特附示例）7.3.4.9（特附示例

273、 2）包含 7.2.2.4.升级执行后，车辆制造商应证明如何实施以下内容：(a)车辆用户能够告知升级成功（或失败）；7.3.3.1（特附示例）9.3.2.16 包含(b)车辆用户能够告知升级所实施的更改和用户手册的所有相关更新（如适用）。9.3.2.17（特附示例 1 和 2）包含 7.2.2.5.在升级执行前，车辆应确保满足了升级的前提条件。7.3.4.3 9.3.1.8 9.3.2.5 包含 112/136 附件附件 2:2021 年年-2022 年年 OTA 召回情况分析召回情况分析 相比传统方式召回，OTA 召回具有以下优点：（1）OTA 单车召回费用低。据统计，OTA 召回费用平均约

274、为 20 元/车，传统方式召回费用约为 600 元/车。其中，2021 年涉及软件类缺陷车辆 302 万辆，按单车节约成本 500 元计，相当于节省费用 15 亿元。（2）OTA 单车召回耗时短。单车召回耗时平均 45 分钟左右，其中软件平均下载时间为 25 分钟，安装时间为 24.5 分钟。最短的单车下载时间仅需 6 秒，安装时间仅需 5 分钟。（3）OTA 召回完成率高。完成率达到 90%以上的占 71.43%，平均召回完成率为 79.65%，高于近 5 年的年均召回完成率（72.36%）。截至 2023 年 11 月底根据公开数据显示21，奔驰、特斯拉、宝马、吉利、丰田、沃尔沃等公司品牌

275、实施 OTA 召回，共涉及 492 万辆。升级涉及座舱、智驾、车身、动力、底盘 5 个功能域。召回案例如表 2-1 所示。113/136 表表 2-1 典型召回案例典型召回案例 车企车企 缺陷缺陷 召回时间召回时间 召回车型召回车型 召回数量召回数量 豪情公司 车辆由于供应商原因，动力电池能量控制模块（BECM）中的微处理器重设，可能导致行驶中高压电池连接断开。行驶中没有预警，高压系统存在意外断开的风险。在极端情况下，行驶途中可能失去动力，存在安全隐患。此时车辆的转向系统、制动系统均正常工作。2021 年 3 月 23 日 2019 年 12 月 9 日至 2021 年 2 月 4 日生产的

276、2021 年款国产极星 2 首发版纯电动汽车 2031 辆 梅赛德斯-奔驰 车辆因通信模块软件的设计问题，当车辆发生碰撞且自动触发紧急呼叫服务时，由车辆碰撞引起的通信模块电源的电压临时下降可能导致车辆自动发送给梅赛德斯-奔驰紧急呼叫中心的车辆位置出现偏差，可能导致救援延迟，存在安全隐患。2021 年 4 月 12 日 2016 年 1 月 21 日至 2020 年 11 月 20 日期间的部分进口和国产 A 级、B 级、C 级、E 级、S 级、GLA SUV、GLB SUV、GLC SUV、GLE SUV、GLS SUV、CLA、SLC、CLS、SL、G 级、AMG GT、EQC 车辆。260

277、0677 辆 华晨宝马 车辆电池控制单元的软件存在设计问题。车辆发生严重的碰撞事故时，电池控制单元的软件不能在要求的时间内确保高压车载网中的中间电路快速放电。造成车辆电气系统的高压可能传输到 12V 电气系统，导致 12V 电气系统及其组件功能损坏，致使碰撞后车辆部分功能（例如警告指示灯、车辆照明或紧急救援电话功能等）无法正常工作，存在安全隐患。2021 年 6 月 1 日 从 2020 年 9 月 1 日到 2021 年 4 月 30 日生产的部分国产 iX3 电动汽车 6636 辆 特斯拉 车辆由于主动巡航控制系统问题，易造成驾驶员在以下情形误激活主动巡航功能：当车辆处于 D 挡，驾驶员再

278、次拨动右侧控制杆试图切换挡位时；在车辆急转弯，驾驶员误触碰并拨动右侧控制杆时等。主动巡航控制被误激活后，如果车辆设置的巡航速度不是当前车速，且当前车速低于设定速度时，车辆会加速到设定速度，出现车辆速度突增情形，会影响驾驶员的预期并导致车辆操控误判，极端情况下可能导致车辆发生碰撞，存在安全隐患。2021 年 6 月 26 日 2019 年 1 月 12 日至 2019 年 11 月 27 日期间生产的部分进口 Model 3 电动汽车；2019 年 12 月 19 日至 2021年 6 月 7 日期间生产的部分国产 Model 3 电动汽车；2021 年 1 月 1 日至 2021 年 6 月

279、7 日期间生产的部分国产 Model Y 电动汽车。285520 辆 114/136 车企车企 缺陷缺陷 召回时间召回时间 召回车型召回车型 召回数量召回数量 奔驰 车辆的通信模块控制单元软件存在问题，导致通信模块不能正常启动或者反复重置；或软件程序设置存在问题，导致紧急呼叫测试模式可能会被用户误激活。这两种情况下，用户都不能通过通信模块实现自动或手动建立紧急呼叫的语音连接，可能会导致救援延迟，存在安全隐患。2021 年 9 月 24 日 在 2020 年 8 月 10 日至 2021 年 6 月 9 日期间生产的部分进口 S 级汽车 17927 辆 奔驰 激活并连接了 Mercedes me

280、 账户的奔驰汽车，会定期从后台服务器自动获取 MBUX 智能人机交互系统配置的更新。由于后台服务器配置文件的偏差，作为车辆与车辆后台定期通信的一部分，本次召回范围内的车辆可能接收了不正确的配置文件，造成车辆 MBUX 智能人机交互系统主机显示屏上的一些功能和应用程序（如电视、数字用户手册）在车辆行驶时不会按预期被禁用。在开始驾驶车辆时或乘员主动选择此类功能或应用程序的情况下，无法排除驾驶员在驾车过程中因此而分散注意力，存在安全隐患。2021 年 12 月 22 日 在 2020 年 8 月 31 日至 2021 年 11 月 10 日期间生产的部分国产 C 级（2095 辆）、进口 S 级车辆

281、（212 辆）2307 辆 特斯拉 部分车辆的热泵电子膨胀阀定位时会有微小移动，因软件（2021.44 至 2021.44.30.6 版本）没有纠正功能，长期可能造成阀门部分开启，热泵压缩机停止工作，车内制热功能失效。在上述状态下，尤其是车外气温低于零下 10 度时，挡风玻璃除霜系统运行达不到国家相关法规规定的除霜效果，除霜功能下降对驾驶员视野造成不良影响，从而增加车辆在寒冷天气行驶时发生碰撞风险的可能，存在安全隐患。2022 年 2 月 18 日 2020 年 12 月 28 日至 2022 年 1 月 15 日期间生产的部分国产 Model 3（12003 辆）和 Model Y（1404

282、4 辆）电动汽车 26047 辆 梅赛德斯-奔驰 车辆由于通信模块控制单元的软件问题，可能导致紧急呼叫时无法建立语音连接或者紧急呼叫功能无法使用，造成相关救援延迟，存在安全隐患。2022 年 3 月 4 日 2021 年 6 月 21 日至 2021 年 11 月 8 日期间生产的部分进口 S 级车辆；2020 年 12 月 9 日至 2021 年 11 月 29日期间生产的部分国产 C 级车辆 30807 辆 115/136 车企车企 缺陷缺陷 召回时间召回时间 召回车型召回车型 召回数量召回数量 梅赛德斯-奔驰 车辆启动时，MBUX 多媒体显示屏可能无法正常启动，造成辅助驾驶员倒车的后视摄

283、像头的图像无法在显示屏上显示，存在安全隐患。2022 年 3 月 25 日 在 2018 年 10 月 29 日至 2021 年 6 月 18 日期间生产的部分进口 A 级、B 级、E 级、CLA、CLS、GLC SUV、GLB SUV、GLE SUV、GLS SUV、AMG GT 汽车；在 2018 年 8月 15 日至 2021 年 10 月 13 日期间生产的部分国产 A级、E 级、GLA、GLB SUV、GLC SUV、EQC 汽车 55630 辆 特斯拉 车辆的后电机逆变器功率半导体元件可能存在微小的制造差异，其中部分车辆使用一段时间后元件制造差异可能会导致后逆变器发生故障，造成逆变

284、器不能正常控制电流。此故障发生在车辆处于停车状态时，会导致车辆无法启动；此故障发生在车辆行驶状态时，会导致车辆失去行驶动力，极端情况下可能增加车辆发生碰撞的风险，存在安全隐患。2022 年 4 月 7 日 2019 年 1 月 11 日至 2022 年 1 月 25 日期间生产的部分进口及国产 Model 3 电动汽车 127785 辆 丰田汽车 车辆由于多功能显示屏系统内部控制程序不当，当实施换挡操作或车辆行驶时，多功能显示屏的画面可能存在不能正常切换的情况，此时显示屏上会保持之前播放的视频画面，可能会分散驾驶员的注意力，存在安全隐患。2022 年 5 月 11 日 2021 年 3 月 3

285、1 日至 2022 年 3 月 17 日生产的部分进口雷克萨斯 NX 260、NX 350h、NX 400h+汽车 6832 辆 特斯拉 车辆在赛道模式下，中央触摸显示屏中的车速区域仅显示车速数值，缺少速度单位（KM/H）。车辆在赛道模式下行驶时，上述情况可能影响驾驶员对车速信息的正确理解，极端情况下会增加发生碰撞事故的风险，存在安全隐患。2022 年 4 月 29 日 2019 年 1 月 12 日至 2022 年 3 月 25 日期间生产的部分进口和国产 Model 3 高性能版电动汽车 14684 辆 特斯拉 部分车辆在准备直流快速充电时或在直流快速充电期间，信息娱乐系统的中央处理器可能

286、没有充分冷却，导致中央处理器运行速度减慢及中央触摸显示屏显示迟钝，严重时中央处理器可能重启从而造成显示屏无法显示。上述故障发生时，倒车影像、风挡（除霜、除雾及雨刮）功能的设置、驾驶档位显示和2022 年 5 月 23 日 2021 年 10 月 19 日至 2022 年 4 月 26 日期间生产的部分国产 Model 3、Model Y 电动汽车 107293 辆 116/136 车企车企 缺陷缺陷 召回时间召回时间 召回车型召回车型 召回数量召回数量 指示灯等将无法正常使用，极端情况下会增加车辆发生碰撞事故的风险，存在安全隐患。丰田汽车 车辆由于车道保持辅助系统（LTA）的内部程序编写不当，

287、导致仅凭 LTA 控制车辆转向时的转向角度修正不足，当车辆通过弯道时，可能达不到预期的辅助修正效果，存在安全隐患。2022 年 9 月 28 日 2021 年 3 月 31 日至 2022 年 4 月 26 日期间生产的部分进口雷克萨斯 NX 260、NX 350h、NX 400h+汽车 8308 辆 丰田汽车 辆由于制动执行器控制单元（ECU）内电动驻车制动系统（EPB）控制电脑电源回路异常检测程序编写不当，将回路中发生的短暂应答延迟现象误认为是异常，可能导致警告灯点亮。此时，如已驻车则无法解除驻车状态，如未驻车则无法使用 EPB进行驻车，存在安全隐患。2022 年 9 月 28 日 202

288、1 年 4 月 19 日至 2022 年 7 月 15 日期间生产的部分进口雷克萨斯 NX 260 汽车 6491 辆 特斯拉 部分车辆由于软件问题，可能出现动力电池电压感测回路反馈电压与电砖真实电压不一致，导致电池管理系统误判，车辆屏幕显示“需要维修”、“安全停靠车辆”等警示，车辆会逐步停止动力输出，极端情况下可能增加车辆发生碰撞事故的风险，存在安全隐患。2022 年 11 月 25 日 2013 年 9 月 25 日至 2020 年 11 月 21 日期间的部分进口 Model S、Model X 电动汽车 67698 辆 特斯拉 部分车辆在从驻车状态唤醒过程中，车辆示廓灯的软件在初始化内

289、部参数时可能会发生错误，导致车辆后部一侧或两侧的示廓灯无法点亮。在黑暗环境下偶发性示廓灯不亮会降低车辆的可见度，极端情况下会增加车辆发生碰撞事故的风险，存在安全隐患。2022 年 12 月 1 日 2020 年 12 月 27 日至 2022 年 11 月 7 日期间生产的部分国产 Model 3 电动汽车；2021 年 1 月 1 日至 2022 年11 月 11 日期间生产的部分国产 Model Y 电动汽车 435132 辆 沃尔沃 部分插电式混合动力车辆由于发动机控制模块的软件控制逻辑错误，可能造成发动机无法启动。如果故障出现，启动车辆时仪表中将出现提示信息（驱动系统需要维修），此时车

290、辆可以通过电动模式行驶。当需要发动机工作时，仪表将再次出现警告2022 年 12 月 16 日 2021 年 3 月 25 日至 2022 年 10 月 8 日生产的 2022、2023 年款进口 XC90 汽车；2021 年 4 月 26 日至 2022 年9 月 29 日生产的 2022、2023 年款 S60 汽车；2021 年 4月 26 日至 2022 年 10 月 8 日生产的 2022、2023 年款6985 辆 117/136 车企车企 缺陷缺陷 召回时间召回时间 召回车型召回车型 召回数量召回数量 但发动机无法启动。如果用户忽视警告和提示信息继续行驶，当车辆高压电池电量耗尽时

291、，仪表将提示“安全停车”且车辆失去电力驱动，存在安全隐患。S90 长轴距汽车；2021 年 3 月 23 日至 2022 年 10 月 5日生产的 2022、2023 年款 XC60 汽车 沃尔沃 部分车辆由于制动控制模块软件与硬件兼容不稳定，制动控制模块可能被误设为故障状态，导致车辆失去制动助力，存在安全隐患。2023 年 2 月 20 日 2022 年 8 月 11 日至 2023 年 1 月 13 日生产的 2023 年款 V60 汽车；2022 年 10 月 11 日至 2023 年 1 月 13 日生产的 2023 年款 V90CC 汽车；2022 年 10 月 11 日至2023

292、年 1 月 13 日生产的 2023 年款 XC90 汽车 4103 辆 特斯拉 部分车辆没有允许驾驶员选择能量回收制动策略；同时，对驾驶员长时间深度踩下加速踏板的情况可能没有提供足够提醒。以上因素叠加可能增加长时间误踩加速踏板的概率，可能增加碰撞的风险，存在安全隐患。2023 年 5 月 29 日 2019 年 1 月 12 日至 2023 年 4 月 24 日期间生产的部分进口 Model S、Model X、Model 3 及国产 Model 3、Model Y 汽车 1104622 辆 特斯拉 部分车辆因车辆控制器接收的制动液位传感器信号的标定范围不足，在制动液位较低时可能无法发出警报

293、，极端情况下影响车辆的制动，增加碰撞风险，存在安全隐患。2023 年 10 月 20 日 在 2021 年 10 月 13 日至 2023 年 9 月 28 日期间生产的部分进口 Model X 电动汽车 4787 辆 118/136 附件附件 3：OTA 企业开发案例企业开发案例 本章梳理典型的 OTA 技术开发、应用案例，分析 OTA 技术赋予整车产品的价值点，讨论 OTA 业务模式，以及案例中企业在 OTA 技术、运营等方面的规划、布局思路。首个实现整车OTA的汽车品牌是特斯拉。从其首款车型Model S上市至今，特斯拉保持了极高的 OTA 频率，涉及的内容生态大到智驾系统、人机交互、动

294、力系统，小到门把手、座椅功能、车机应用，不一而足。在国内市场，以小鹏、蔚来为代表的新势力车企也将整车 OTA 作为自身产品“智能化”的特色功能，且坚持自主研发。大部分整车企业也在激烈竞争中意识到利用 OTA 提升用户体验的重要意义，普遍选择与专业的 OTA 解决方案商合作，快速实现产品量产应用，该领域典型的供应商有爱瑟福、艾拉比、科洛达、哈曼等。1 小鹏汽车 小鹏汽车主打基于全栈自研的智能科技，得益于集中式新型电子电气架构，成为国内较早的能够真正实现整车 FOTA 的车企。OTA 是小鹏旗下所有车型必备的基础功能之一，2019 年 1 月以来，累计通过 OTA 向 G3、P7 及 P5 车型用

295、户推送了近 30 次的重大版本更新，新增功能 190 多项，优化功能 2400 多项，累计OTA 次数超过 38 万次。小鹏汽车坚持“OTA 升级的核心是安全和稳定”的理念，践行将 OTA 服务发展成用户基础服务。公司设有专门针对 OTA 升级的组织机构，由各中心的负责人共同决策功能选择和技术要求。在确定功能后，OTA 升级组织机构与各个研发团队协调、制定日程计划，并针对升级的功能进行责任分工，例如 NGP 的开发涉及到包括自动驾驶、互联网、客户服务等多个部门。项目开发完成后还需要完成测试以及验证，最终完成发布。发布后 OTA 运营组还需要解决发布过程中的网络保障以及用户的建议选取等问题，进一

296、步做新的优化，为下次 OTA 做预备。小鹏汽车致力于建立一套对整个硬件配置以及软硬件结合的调节机制配合体系，实现全车 ECU 升级。例如，小鹏 P7 车型在总控上拥有 30 多个 ECU，这些 ECU 之间通过车载内部网络形成一整套沟通交流机制，与 P5、G9 等车型一 119/136 样，整车所有 ECU 均可升级。在整车系统领域，小鹏汽车 OTA 范围包括：动力系统、智能座舱系统、车身系统、智能驾驶系统、底盘系统等全功能域，主要升级内容以智能座舱系统和智能驾驶系统为主。智能座舱功能含全场景语音交互、音乐座舱、车身电子、应用生态以及用户用车习惯设置、其它信息娱乐等；在智能驾驶功能方面，OTA

297、 范围包括：ICA（智能巡航辅助）、LCC（车道保持功能）、TJA（交通拥堵辅助系统）、ACC（自适应巡航）、ALC（自动变道辅助）等、VPA（记忆泊车）、记忆泊车路线分享、高速 NGP 等，未来还将升级城市 NGP、AVP（自主代客泊车）等。当系统推送升级 OTA 请求时，小鹏汽车用户还可进行预约处理，避免对当前的驾驶行为或智能体验造成影响。此外，在获得用户确认的条件下，车机系统可在夜间自动升级，便利服务用户。表表 4-1 小鹏汽车重要小鹏汽车重要 OTA 节点及功能节点及功能 时间时间 车型车型 升级内容与重要功能升级内容与重要功能 2019 年 1 月 小鹏 G3 首次 OTA，对 XP

298、ILOT、XmartOS 进行优化提升。新增了车辆钥匙召唤功能。实现了 G3 上市发布会上对软件快速迭代的承诺。2019 年 6 月 小鹏 G3 开放 ICA 功能，进入 XPILOT 2.0 智能时代。2019 年 7 月 小鹏 G3 通过 OTA 为小鹏 G3 开放了 TJA/ACC/ALC 智能驾驶功能，进入XPILOT2.5 智能时代。2019 年 11 月 小鹏 G3 新增 DOW 车门开启预警功能及智能除味功能。优化了整车 OTA 服务，往后可通过“小鹏汽车”手机 APP 进行远程控制车辆升级，成为国内首个实现手机操控车辆 OTA 的车企。2020 年 3 月 小鹏 G3 疫情期间

299、，通过对空调系统紧急 OTA 升级优化，为所有车辆新增了高温抑菌功能。2020 年 10 月 小鹏 P7 为车型新增全场景语音功能，具备连续对话、可见即可说、语义打断、自动过滤无效语义、双音区锁定等高阶能力。2021 年 1 月 小鹏 P7 为智尊版、鹏翼版开放高速 NGP 功能，进入 XPILOT 3.0 时代。2021 年 6 月 小鹏 P7 开放了停车场记忆泊车、通过语音指令控制 NGP。2021 年 12 月 小鹏 P7 增加停车场记忆泊车路线分享，优化 NGP 系统。2022 年 3 月 小鹏 P5 P5 车型通过激活了激光雷达硬件配置，新增了 10 项功能，优化了 38项体验，其中

300、主要升级的核心功能包括 VPA-L（跨楼层停车场记忆泊车）、高速 NGP、LCC、全新 AI 声音、全场景语音、智能音乐座舱和应用生态等 7 大模块。2022 年 6 月 小鹏 P5 通过 3.2.0OTA 升级包为车型增加激光雷达的更广泛应用，增强高速NGP 功能和性能，极大提高驾驶舒适度，并新增 ACC 增强版和 LCC增强版、VPA 增强版。120/136 2 蔚来汽车 蔚来是全球首家通过完全自主研发 OTA 系统并实现大规模量产整车 FOTA的汽车品牌。从系统构建之初，便从整车架构、信息管理系统、组织流程体系等方面统筹考虑 OTA 升级与业务的融合，真正做到覆盖产线、售后、以及 OTA

301、 升级的企业级统一的软件升级管理体系。自 2018 年 10 月首次 OTA 截至 2022 年 7 月的 Aspen 3.2.0 发布，蔚来汽车已累计迭代 81 个软件版本，持续优化超 400 项体验，新增 200 项以上功能，涉及包括车身域、底盘域、动力域、数字座舱域以及辅助驾驶域在内的全车所有功能域。覆盖 4 款车型，累计完成超过 160 万车次软件升级。在不断完善 OTA 体系能力建设的同时，蔚来汽车紧密关注 OTA 相关法规标准动态，并及时调整以满足相关要求。在国内法规方面，2021 年 10 月参与了 汽车软件升级通用技术要求（草案）合规检验预演测试，成为针对该标准进行试验测试的首

302、批汽车企业之一。在国际法规方面，在 2022 年 4 月通过了 UN R156 软件升级管理系统(SUMS)体系认证，并于同年 6 月获得旗下两个车型平台的型式(VTA)认证。蔚来汽车 OTA 升级管理体系是一个以整车软件升级为基础，适应不同软硬件配置，覆盖多车型、多区域的综合软件升级管理平台。从升级对象角度，涉及两大架构平台，支持超过 40 个不同种类 ECU 升级，所支持升级的 ECU 涉及包括以太网、CAN、LIN 等在内的多种车内网络类型。根据业务发展需要，还可以扩展支持多品牌、多平台部署。除了整车 ECU 外，智能外设、关联设备，如智能钥匙等也在 OTA 升级管理体系的覆盖范围内。从

303、升级类型角度，蔚来同时支持整车固件(FOTA)、应用软件升级(SOTA)、配置更新等，FOTA 保证了更新深度和彻底性，SOTA 和配置更新保证了快捷性和灵活性。表表 4-2 蔚来汽车重要蔚来汽车重要 OTA 节点及功能节点及功能 NIO OS 1.0 阶段阶段 2018 年年 10 月月2019 年年 5 月月 更新要点：OTA 升级管理体系运行的开端，更注重优化与完善车辆功能 NIO OS 1.1.1 新增 360 度全景倒车影像融合雷达距离的显示与报警，优化 360 度全景倒车影像的合成算法。121/136 NIO OS 1.1.2 新增车辆前后车身控制模块的 FOTA 远程升级，用户离

304、车后车辆档位自动切换至 P 档的功能。NIO OS 1.2.0 作为 2018 年底一个阶段性的软件迭代，新增远程空调预约功能、电池预约加热、AEB 自动紧急制动等 12 项新功能。NIO OS 1.2.1-1.2.3 新增百度地图导航功能、自适应巡航等功能，同时包含了蓝牙通话、低温驾驶性能、开门预警等多项优化。NIO OS 1.3.0 作为 1.0 阶段最后一个版本，新增了行车记录仪、前排舒适进出功能、车辆访客模式等功能。NIO OS 2.0 阶段阶段 2019 年年 6 月月2021 年年 7 月月 更新要点：高频迭代，以 NIO Pliot 智驾系统为代表，智能化水平持续提升 NIO O

305、S 2.0.0 1、开启 NIO Pliot，引入道路限速标识识别（TSR）、道路自动保持（LKA）、前侧来车预警（CTA-F）、转向灯控制变道（ALC）、自动泊车辅助（APA）、防二次碰撞等功能；2、引入全新的交互界面，整体风格更加简洁实用。NIO OS 2.1.0 新增了全自动泊车系统（S-APA），以及自适应巡航及自动辅助驾驶下的动能回收、自动辅助驾驶的 NOMI 表情及语音提醒等功能。NIO OS 2.2.0 新增后雨刮自动启动功能。NIO OS 2.3.0 辅助驾驶相关功能更新包括车道自动模拟（ALS）功能、窄路辅助（SDIS）功能、驾驶模式更新；其他功能包括疲劳驾驶监测（DDD）功

306、能、NOMI 表情及语音控制等。NIO OS 2.4.0 推出源于用户提议的“雪地模式”，同时新增座椅及方向盘初始化、主驾座椅轻松进出、手动关闭日间行车灯功能。NIO OS 2.5.0 在自动辅助驾驶方面，新增了带行人及自行车识别的自动紧急制动功能以及超车辅助功能；智能互联部分，新增远程方向盘/座椅加热、电池智能预热开关、车内照片分享功能。NIO OS 2.6.1 新增悬架轻松进入、NFC 卡片钥匙支持、NOMI 支持双唤醒词 NIO OS 2.6.5 新增 NIO OS 浅色模式功能。NIO OS 2.7.0 自动辅助驾驶部分，新增领航辅助(NOP)、来车预警-主动制动（CTA-B）功能；数

307、字座舱部分，新增 5.1 沉浸式环绕声支持，基于摄像头的驾驶员疲劳监测。NIO OS 2.8.0 新增离车自动上锁、副驾驶座椅记忆、副驾驶座椅轻松进出功能。NIO OS 2.9.0 辅助驾驶方面，新增视觉融合全自动泊车系统、车辆近距召唤（NBS）；新增智能钥匙/NFC 卡片钥匙绑定不同账户、中控屏调整副驾驶座椅及语音一键复位功能。NIO OS 2.10.0 新增二代换电站支持及一键自动泊入，动态仪表界面内容识别显示、辅助驾驶注意力监测（AMP）、锁车自动关窗、空调干燥除味。NIO OS 3.0 阶段阶段 2021 年年 8 月起月起 NIO OS 针对不同代际的平台车型，采用独立的命名体系 A

308、spen 3.0.0 全新用户界面及交互设计（UIUX），对中控屏、仪表屏及抬头显示（HUD）界面布局、交互逻辑、动画效果及整体视觉的一次彻底更新；同时新增“潮汐”和“全民 K 歌”功能。Aspen 3.0.5 新增 NIO Pilot 安全使用指南，出于安全用户需学习安全指南后使用 NIO Pilot。122/136 Aspen 3.0.7 新增电池充电预热功能，前置预热电池，节省快充时给电池升温的时间，提高快充效率。Aspen 3.1.0 辅助驾驶方面，新增一键调节巡航车速、蓝牙车辆近距召唤功能；智能互联部分，新增英文版车机界面、蓝牙解锁启动、任务管理器；Aspen 3.1.2 新增高德地

309、图支持，进入双地图时代。Aspen 3.2.0 新增快捷场景应用，实现车机功能自由组合、智能联动，满足个性化用车场景；此外还增加了语音输入法、智能车距调节、起步提醒等功能。3 特斯拉 特斯拉最先将整车级 OTA、软件付费升级等理念引入汽车行业，并在技术开发与应用上获得成功。其量产上市的 Model X、Model S、Model 3、Model Y等车型均具备整车级 OTA 能力。特斯拉采用集中式的电子电气架构，将电动车控制系统作为一个整体，自主研发操作系统，从底层设计上即嵌入 OTA 系统和功能。自 2012 年至 2022 年上半年的十年间，特斯拉通过 OTA 执行了 70 余次软件版本更

310、新（表 4-3），范围覆盖自动驾驶、智能座舱、动力、车身、底盘等功能域。其历次 OTA 更新的目的，一类是根据开发计划、分阶段释放重要功能，如 2015年 V6.1 版本开始引入智能驾驶功能，2018 年 V9.0 版本推出导航辅助驾驶功能；另一类是用来快速优化已有功能或解决售后问题，如 2017 年通过 OTA 为部分车主临时释放动力电池剩余电量、增加续驶里程以逃离飓风山竹，2018 年通过 OTA将 Model 3 的紧急制动距离缩短 6 米，2022 年通过 OTA 召回的方式解决中控信息娱乐系统 CPU 过热隐患等。特斯拉通过 OTA 技术实现了软件升级服务的云端部署、远程执行，用软件

311、的方式在一定程度上取代传统 4S 店的功能，并且做到即时响应用户需求，赋予电动车更强的生命力，真正实现了“软件定义汽车”。表表 4-3 20122022 年间特斯拉整车产品年间特斯拉整车产品 OTA 的主要内容的主要内容 时间时间 OTA 次次数数 系统版本系统版本 升级的主要内容升级的主要内容 2012 年 6 V4.0 新增主驾座椅记忆、怠速蠕行模式、智能语音交互功能、更新 EPA 续航标准。2013 年 8 V5.0 新增 3G 无线网络连接、Wi-Fi 连接 2014 年 5 V6.0 中文导航和地图服务、语音命令设定目的地、找到最近的超级充电站、智能空气悬架、手机远程启动 123/1

312、36 时间时间 OTA 次次数数 系统版本系统版本 升级的主要内容升级的主要内容 2015 年 3 V6.1V7.0 首次提升 Model S 加速能力，优化主动巡航控制，新增自动远光灯等，首次推出 Autopilot 自动辅助驾驶，包含识别当前路段限速值、自动泊车、启动辅助变道等 2016 年 2 V7.1V8.0 优化 Autopilot，新增垂直泊车、遥控召唤。全新界面 UI 设计，新增实时路况和路线规划功能 2017 年 4 V8.1 优化 Autopilot，提升自动辅助变道限速值至 150 km/h，新增自动紧急制动等功能 2018 年 7 V9.0 首次推出导航辅助驾驶（NOA）

313、功能，新增行车记录仪、盲区警告、哨兵模式等安全功能。车载娱乐系统首次推出了 QQ音乐，并上线首款手柄游戏 2019 年 8 V10.0 上线 Tesla 剧场、引入视频、游戏等更多娱乐软件，优化哨兵模式、遥控召唤。国内同步上线 NOA、哨兵模式等功能，Model 3 功率提升 5%2020 年 17 V10.2 提升 Model S、X 零百加速时间、续航里程，新增红绿灯识别、天气、空气质量检测、手套箱密码等，国内新增 B 站、斗地主等娱乐软件，地图服务商由腾讯更换为百度 2021 年 9 V10.2V11 优化电池管理，音响音效，新增辅助驾驶功能动物可规化、导航车道引导、导航途经点设置、疲劳

314、检测语音提醒、个性喇叭扩音器、灯光秀、自动保存行车记录仪视频、自动座椅加热、娱乐 App 等 2022 H1 4 V11 新增导航路况、KTV、挡风玻璃雨刮器除霜等功能，优化空调、童锁控制、充电时间、车机应用等 4 爱瑟福 爱瑟福（Excelfore）是汽车 OTA 技术的创新企业，主营业务为智能网联系统，包括车辆 OTA 系统、远程诊断和数据分析及处理、车内局域网系统、车辆和云端的互联等。其 OTA 平台名为 eSync，支持目前所有主流架构的 T-BOX，支持整车核心 ECU 的刷写升级，可以向用户提供车载 ECU 软件接口协议规范及整体安全加固方案，协助客户掌握核心技术及进行关键能力建设

315、。eSync 平台采用“服务器-客户端-代理”架构，在云端与车载终端设备之间建立可扩展且安全的双向数据管道，能够更新软件和固件，并可以从车辆中任何符合 eSync 的终端设备收集实时运行数据。eSync 数据管道的双向功能为聚集“大数据”并在云与车辆中的许多控制器和传感器之间建立交互式学习循环提供了基础。该系统的组件包括差分或增量更新器、增量更新器和全更新器格式，支持在车辆行驶过程中实时进行 OTA。同时，eSync 具有可扩展性，可以根据客户的 124/136 OTA 要求进行扩展，并具有长期规模经济的标准化和安全性。爱瑟福能够为客户提供云端、车端、测试、能力建设等全方位的开发服务（表4-4

316、），能够提供灵活多样的 OTA 项目合作方式。既支持具体车型的 OTA 开发项目，也支持与车企一起实现 OTA 能力共创，同时满足客户对 OTA 前期规划及后期 OTA 运维的需求。目前主要的合作模式有五种：模式一：开发 OTA 平台，搭建一套车企统一的 OTA 管理及运维的平台，并承担车端相关零件 SDK 的开发服务；模式二：根据车企需要，实现 N 年内/指定几款的车型 OTA 开发任务，满足车企的 OTA 开发服务；模式三：根据车企需求，共同开发某一款车型，并开放源代码，以实现车企后续自主开发的能力自建；模式四：提供 OTA 运维及运营支持服务，满足车企长期的 OTA 规划，开发，运营的需

317、求；模式五：协助车企构建自己的 OTA 的相关规范标准，建立对 OTA 零件端测试准入的标准。表表 4-4 爱瑟福爱瑟福 OTA 技术开发业务范围技术开发业务范围 开发业务开发业务 具体业务具体业务 云端 开发 1 云端 OTA 管理平台的开发及定制化开发需求 2 打通云端 OTA 系统与 OEM 其他系统的通讯及数据交互 3 构建车云通讯协议并满足车企的自定义功能需求 车端 开发 4 车端根据车型的不同，实现主控节点在不同零件及系统的开发工作 主控节点在 T-BOX、车机、网关或域控制器 支持的操作系统：Linux，QNX，Android 等 支持的技术架构：AUTOSAR AP/CP，SO

318、A 等 5 实现目标零件的 OTA 能力构建（整包，差分等标准化升级服务）车机的升级及 HMI 的交互 域控制器的升级 零件端升级服务接口：Some/IP，DoIP，Https 等 测试 服务 6 实现以上系统的测试工作：包括云端测试，性能测试，接口测试，异常测试，车端单件测试，稳定性测试，车云集成测试，实车测试以及各场景测试，合规性测试等 7 帮助车企创建 OTA 自动化测试平台，实现 OTA 的自动化测试能力 能力 建设 8 帮助车型实现车辆 OTA 版本规划，OTA 任务的灰度测试，OTA 数据分析等工作 9 提供 OTA 车企标准化流程及文档的建立 10 协助车企进行知识产权及相关专利

319、的申请 125/136 附件附件 4：OTA 系统功能测试主要测试项系统功能测试主要测试项 1 测试概述 基于 OTA 的架构设计、功能设计进行测试研究，测试系统功能是否符合主机厂定义的需求规格说明书，核实系统功能是否完整，且没有冗余和遗漏的功能 1.1 OTA 云平台测试 具体内容具体内容 测试要求 云平台功能要求与车端相互校验，进行身份确认；与车端进行 OTA 相关数据交互；基于车端数据与不同软件包平台对接以获取适宜的软件包；将从各软件包平台获取的软件包推送给车端；在车端升级过程中，提供安全算法支持；OTA 任务下发过程管理；OTA 任务权限管理；OTA 软件包管理。测试方法 校验测试：包

320、括支持的身份验证方式的种类、与多车端同时验签的测试；数据通信测试：数据通信稳定性、与多车端同时通信测试；多平台交互测试：与 PKI 系统验签交互测试、多并发量的验签测试、证书申请测试、多平台多并发量不同软件包请求时软件包的获取测试；软件包推送：给多车端推送不同软件包的测试；安全算法支持：多并发车端请求安全算法以及响应的测试；OTA 过程管理：基于设计需求，验证 OTA 任务的过程管理，包括任务的创建、任务的下发，执行过程中结果的反馈，日志记录等。任务创建与下发：要验证任务是否基于设计进行关联创建限制或者多选项设计，任务下发是否适用于批量下发，测试时需结合实际需求，既要保证任务创建和下发的灵活性

321、，又要保证使用过程的便利性；过程反馈：需基于需求设计对执行过程中的关键节点进行反馈；日志记录：需结合设计需求，验证 OTA 过程关键点是否均有记录，如升级前版本、升级后版本、升级时间、任务名称、任务详情等信息，满足升级信息可追溯的需求。OTA 软件包管理：基于各厂家 OTA 软件包的发布流程，进行针对性测试，重点关注软件包验证环节、软件包发布策略、软件包上传下载权限、软件包加解密等过程实现情况。1.2 OTA 链路测试 126/136 具体内容具体内容 通信链路要求 数据传输质量：保证数据正确可靠传输；数据传输速率：对平台收发数据能力，车端收发数据进行要求，以满足期望的传输速率；数据传输安全：

322、对各数据传输链路传输方式进行安全要求，比如握手校验，约定通信密钥，支持的加密算法等，检验各链路是否与要求保持一致。测试方法 按照约定规则，创建车端与平台的传输场景，通过获取数据日志、通信数据抓包等形式，对数据进行分析校验，检验是否有握手校验、加密传输，是否具备支持多种加密算法；制造极限情况，验证车端在 4G、5G 等方式下的数据传输速度。1.3 OTA 车端测试 车端测试包括 OTA 升级提醒、OTA 软件包下载、OTA 软件包安装、OTA 状态反馈等环节。（1）OTA 升级提醒 具体内容具体内容 测试要求 OTA 云平台与 OTA 主控、OTA 主控与显示屏之间可接收与发送升级提醒相关信息。

323、测试方法 显示屏测试:模拟 OTA 主控和用户操作信号，验证显示屏是否能基于控制信号进行对应提醒；OTA 主控测试:模拟 OTA 云平台推送和显示屏操作信号，验证 OTA 主控是否能基于操作信号进行信号转换与传输；（2）OTA 软件包下载 具体内容具体内容 测试要求 需验证 OTA 主控的软件包下载能力，可应对各种异常情况。测试方法 对网络切换、网络信号异常、软件包大小大于实际可存储大小、下载中途断电、源数据输出限制、源数据地址文件为空、下载超时限制、下载异常提醒等多种情况进行验证。（3）OTA 软件包安装 具体内容具体内容 测试要求 本地安装过程中需着重对安装条件进行验证测试，需保证在安装中

324、及安装后不影响车辆安全。测试方法 OTA 安装前检验当前版本是否满足升级要求并进行记录。测试多种条件（如车速、转速、手刹、ON 档、电池电量、通讯这些信号丢失、正常、异常）组合场景下，T-BOX 对 OTA 安装任务执行情况是否满足设计要求；安装过程中执行可能影响车辆安全、驾驶安全以及影响软件升级成功的操作，验证是否满足设计要求；安装完成后对升级版本进行验证确认，如读取软硬件版本、或其他标识字段，以验证升级版本的正确性。（4）OTA 状态反馈 127/136 具体内容具体内容 测试要求 保证 OTA 云平台与 OTA 主控、OTA 主控与显示屏、OTA 主控与被刷件的交互均能正常响应。测试方法

325、 针对单部件的测试可按照设计规范，模拟对应外围交互报文，各被测件需能正常响应。1.4 系统测试 系统测试是在完成单部件各功能验证后进行，系统测试重点在搭建系统级测试环境，最终使用所有真实控制器、真实 OTA 平台进行测试，搭建环境后先进行主流程功能测试，其次重点验证升级策略（不同软件版本间的兼容测试、软硬件间的兼容测试）和其他异常或压力测试（如双版本乒乓测试、不间歇循环升级测试）。（1）主流程功能测试 具体内容具体内容 测试要求 区别于各部件单测，验证 OTA 整个升级过程的匹配度、通畅性和稳定性。测试方法 包括车端与平台的注册、车端数据上报、OTA 任务创建、软件包获取、OTA 任务下发、O

326、TA 任务执行、状态上报、升级验证（如功能继承性测试、被升级软件的默认配置检查、被升级软件的用户自定义配置检查）。（2）升级策略测试 具体内容具体内容 测试要求 升级策略需要基于最新的状态去验证，确认是否满足设计要求。测试方法 测试时按照当前升级策略，先按照正向逻辑进行验证，随后再构造异常策略进行验证，确认升级策略是否满足主机厂定义的需求规格说明书。（3）其他异常或压力测试 具体内容具体内容 测试要求 不断施加越来越大的负载验证 OTA 过程中各部件、系统的最大服务级别。测试方法 对各 OTA 控制器进行双版本乒乓测试，验证如刷写次数限制等功能；通过创建多个 OTA 任务不间歇循环升级，检验

327、T-BOX 对连续升级的支持情况；创建其他异常场景以验证多维能力，如软件包大小小于 T-BOX 缓存大小，但大于被刷控制器缓存大小的场景。（4）升级安全测试 具体内容具体内容 测试要求 通过升级文件的前后对比，测试车辆安全参数和安全性能 测试方法 通过升级文件解析工具，获得 OTA 真实升级文件内容，甄别车辆安全性与非安全性参数；对比现有 OTA 文件及前一次 OTA 文件的差异性，形成差异化的安全参数和安全性能参数对比库；基于识别出的安全参数和安全性能参数对比库，设计测试方法与测试工具，测试升级文件对车辆安全性能的影响。128/136 图 2 系统测试环境示例 1.5 实车测试 实车测试是系

328、统测试的升级版，但不能被系统测试所取代。台架系统测试无法模拟实车复杂的电气环境，实车测试是在部件级测试完成基础功能验证，系统测试完成兼容性确认，将基本功能错误、异常场景兼容性问题都排查完成后，OTA真正应用前的最终验证。实车测试需覆盖到不同配置的车型，同时考虑用户在升级前、中、后可能进行的操作，以及实车非 OTA 控制器对 OTA 的影响，谨防因只关注 OTA 正常执行而遗漏一些操作导致的整车电气环境变化对 OTA 的影响，如等待升级过程中操作中控屏听音乐、看视频行为等，以及升级过程对双闪、手刹、开关门等安全相关的操作限制等。图 3 实车测试环境示例 2 异常场景测试 129/136 异常测试

329、包含异常场景测试和功能交互测试。2.1 异常场景测试 异常场景测试主要是升级流程中各种异常条件的构造从而完成对功能异常分支的测试覆盖。（1）版本检测：版本检测发起的方式通常有中控屏，手机 app，OTA 主节点，和后台更新任务。对应的异常场景和触发方式如下：序序号号 触发方式触发方式 异常场景异常场景 中中控控 手机手机 app OTA 主节点主节点 云平云平台台 1 OTA主节点未找到保存在本地的 ECU 版本信息文件 1 1 1 1 2 OTA 主节点接收 TSP 平台返回结果超时 1 1 3 手机 APP 发送版本检测请求失败 1 4 TSP 平台获取整车 ECU 软件信息超时 1 5

330、无法接收到 TSP 平台推送的版本信息 1 1（2）升级包下载：下载升级包的方式通常有中控本地触发，手机 app 远程触发，自动触发，和静默下载。对应的异常场景和触发方式如下：序号序号 触发方式触发方式 异常场景异常场景 中控下载中控下载 手机手机 app 下载下载 自动下载自动下载 静默下载静默下载 1 T-BOX 与 TSP 后台连接中断 1 1 1 1 2 OTA 主节点存储空间不足 1 1 1 1 3 车辆不处于上电状态 1 1 4 TSP 平台判断下载任务失效 1 1 1 5 安装包校验失败 1 1 1 1 6 整车异常断电 1 1 1 7 车辆电源状态不满足 1 1 1（3)版本安

331、装：版本安装的方式通常有中控屏发起的立即安装，手机发起的立即安装，云端配置的工厂升级和中控屏或手机发起的预约安装。对应的异常场景和触发方式如下：序号序号 触发方式触发方式 异常场景异常场景 中控屏发中控屏发起的立即起的立即安装安装 手机发起的手机发起的立即安装立即安装 云端配置云端配置的工厂升的工厂升级级 中控屏或手机中控屏或手机发起的预约安发起的预约安装装 130/136 1 进行前置条件检测时，任意条件不满足：电源状态不符合云端配置 车速阈值 低压蓄电池电量阈值 动力电池电量 档位为非 P 档 手刹状态为释放状态 非充电状态 非预约充电状态 车门上锁状态 整车防盗状态 1 1 2 用户按下

332、取消升级按键 1 1 3 升级包安全校验失败 1 1 1 1 4 无法进入 OTA 模式 1 1 1 1 5 低压 ECU 安装失败 1 1 1 1 6 高压 ECU 安装失败 1 1 1 1 7 低压蓄电池电量不满足高压 ECU 回滚时间 1 1 1 1 8 整车 ECU 安装失败，回滚失败 1 1 1 1 9 低压蓄电池电量不满足高压 ECU 升级时间 1 1 1 1 10 请求智能补电，收到补电失败状态信息 1 1 1 1 11 退出 OTA 模式失败 1 1 1 1 12 请求补电时无法获取电量/电压信号 1 1 1 1 13 正在进行预约充电 1 1 1 1 14 整车电源状态 ON

333、 1 15 请求整车远程上电失败 1 16 预约升级时间到，OTA 主节点检测电源模式为 ON 情况时，整车已上电 1 17 中控显示预约时间到时，用户选择取消升级 1 2.2 功能交互测试 功能交互测试是在 OTA 过程中对相关模块交互做针对性的测试。模块名称模块名称 功能屏蔽功能屏蔽 测试方法测试方法 车机 中控相关功能如蓝牙通话、功放、媒体、影像、语音交互等 使用对应功能确认是否屏蔽 仪表 仪表禁止报警灯显示 发送对应报文确认是否禁止 网关 禁止路由转发OBD 接口的诊断报文；发送对应报文确认是否禁止 远控终端 无法使用远程控制、数字钥匙、数据上传、CALL 类使用对应功能确认是否屏蔽 131/136 功能 档位控制器 禁止发出档位控制单元发出换挡请求；发送对应报文确认是否禁止 制动系统 保持驻车制动状态不变 发送对应报文确认是否禁止 车身域控制器 启动按钮屏蔽，遥控启动、远程启动屏