SUMS体系：GB44496标准解读

1 前言

1.1 标准背景

汽车软件升级正引领汽车产业深刻变革，贯穿于研发、生产及售后等各个环节，为车辆提供固件更新、功能优化及漏洞修复等核心服务，推动了汽车行业的创新与发展。
软件升级对传统汽车管理制度构成了挑战，可能引发产品生产一致性的重大风险。不规范的软件升级操作也带来了不容忽视的安全隐患，如部分车型曾因软件升级问题导致用户无法有效控制车辆，严重威胁用户生命财产安全。
标准的制定和实施将为支撑技术创新、保障用户安全、落实监管政策奠定坚实的基础。

1.2 标准概述

2024年8月23日，GB 44496-2024《汽车软件升级通用技术要求》强制性国家标准由国家市场监督管理总局、国家标准化管理委员会批准发布（国家标准公告2024年第18号文），将于2026年1月1日起实施。

该标准由工业和信息化部提出并归口。

• 标准名称：GB 44496-2024《汽车软件升级通用技术要求》
• 标准性质：强制性国家标准
• 标准范围：文件规定了汽车软件升级的管理体系要求、车辆要求、同一型式判定、机动车产品使用说明书，描述了相应的试验方法。文件适用于具备软件升级功能的 M 类、N 类和 O类车辆。

1.3 标准结构

2 关键术语和定义

• 标准章节 3.2

原文条款：
软件升级　software update
将某版本的软件通过升级包更新到新版本（包括更改软件的配置参数）的过程。
注 1：“软件升级”也称“软件更新”。
注 2：“软件升级”包含在线升级和离线升级。
​
条款理解：
软件升级的重点体现在两个点，一是用到了升级包；二是出现了软件版本的更新。

• 标准章节 3.3

原文条款：
在线升级 over-the-air update；OTA update
通过无线方式而不是使用电缆或其他本地连接方式将升级包传输到车辆的软件升级。
注1：“在线升级”也称“远程升级”。
注2：“本地连接方式”一般指通过车载诊断（OBD）接口、通用串行总线（USB）接口等进行的物理连接方式。
​
条款理解：
在线升级的重点体现在两个方面，一是通过无线方式传输升级包，例如蓝牙、蜂窝网络等模式都属于无线；二是将升级包传输到车辆上。

3 软件升级管理体系要求

3.1 一般要求

• 标准章节 4.1.1

原文条款：
当生产具有软件升级功能的车辆时，车辆制造商应具备软件升级管理体系。
​
条款理解：
具备软件升级管理体系是生产具有软件升级功能的车辆的前提。

• 标准章节 4.1.2

原文条款：
对于每次软件升级，车辆制造商应记录并安全存储4.3要求的相关信息，该信息至少应保存至车型停产后10年。
​
条款理解：
本条款明确要求每次软件升级都记录并存储4.3的全部信息。保存至车型停产后10年的要求与联合国UN R156保持一致。

• 标准章节 4.1.3

原文条款：
当具备软件识别码时，无论车辆上是否存储软件识别码，车辆制造商至少应确保：
a) 每个软件识别码是唯一且可识别的；
b) 每个软件识别码与型式批准相关车辆系统中所有电子控制单元（ECU）的软件版本信息构建明确的对应关系；
c) 当车辆型式发生扩展或产生新车辆型式时，同步更新相应软件识别码的所有信息。
​
条款理解：
1）“具备软件识别码”是指车辆制造商使用了软件识别码，但不强制存储在车辆上。
2）“车辆型式发生扩展或产生新车辆型式时”可以理解为需要进行新的强检试验。

• 标准章节 4.1.4

原文条款：
当不具备软件识别码或虽具备软件识别码但未在车辆上存储时，车辆制造商至少应确保：
a) 向授权机构声明车辆中型式批准相关车辆系统中所有电子控制单元（ECU）的软件版本信息；
b) 对所声明软件版本进行软件升级时，同步更新 a）中的声明信息
​
条款理解：
本条款包括“不具备软件识别码”或“虽具备软件识别码但未在车辆上存储”两种情况。

3.2 过程要求

• 标准章节 4.2.1

原文条款：
应具备一个过程，能唯一地标识与型式批准或召回相关车辆系统中所有初始和更新的软件版本信息以及相关硬件部件信息，其中软件版本信息应至少包括软件版本号和相应升级包的完整性校验值。
​
条款理解：
本条款的目的是对与型式批准或召回相关车辆系统中所有初始和更新的软件相关信息进行管理。包括两个方面，一个是“型式批准相关的”，一个是“召回相关的”。
“标识”是个动词，是过程中应该有的动作，“唯一地”是用来修饰“标识”。

• 标准章节 4.2.2

原文条款：
当具备软件识别码时，应具备以下过程。
a） 在软件升级前后，能访问软件识别码相关信息。
b） 在软件升级后，能更新软件识别码相关信息，至少包括以下信息：
1） 所有相关的软件版本号；
2） 所有相关升级包的完整性校验值。
c） 能验证软件识别码对应的软件版本信息与相关车辆系统中软件版本信息保持一致。
​
条款理解：
​

• 标准章节 4.2.3

原文条款：
应具备一个过程，能识别软件升级的目标车辆。
​
条款理解：
“目标车辆”是指单个车辆（例如使用 VIN 标识单个车辆）。

• 标准章节 4.2.4

原文条款：
应具备一个过程，能确认软件升级与目标车辆配置兼容性。该过程至少应包括在发布软件升级前，确认目标车辆最新已知软硬配置的兼容性。
​
条款理解：

• 标准章节 4.2.5

原文条款：
应具备一个过程，能识别被升级的车辆系统与车辆其他系统之间的相关性。
​
条款理解：
分析相关性是为了确定软件升级可能影响的车辆系统范围。分析结果也为4.2.6、4.2.7、4.2.8做支撑

• 标准章节 4.2.6

原文条款：
应具备一个过程，在发布软件升级前，能评估、识别和记录软件升级是否会影响型式批准相关车辆系统，至少应包括软件升级是否会影响相关参数。
​
条款理解：
本条款要求评估哪些软件升级会对那些型式批准相关车辆系统产生影响，包括是否对参数造成影响。
此处的“参数”不是指软件参数，而是指描述车辆系统型式批准的相关参数。

• 标准章节 4.2.7

原文条款：
应具备一个过程，在发布软件升级前，能评估、识别和记录软件升级是否会增加、更改或启用在型式批准时不存在或未启用的任何功能，或是否会更改、禁用型式批准相关标准法规中定义的任何其他参数或功能。该评估至少应包括：
a) 型式批准相关的信息条目是否需要修改；
b) 型式检验结果是否不再适用软件升级后的车辆；
c) 对车辆功能的修改是否影响车辆的型式批准结果。
​
条款理解：
本条款与 4.2.6 是相关条款，4.2.6 主要要求是否有影响，本条款进一步要求有哪些影响。
此处的“参数”不是指软件参数，而是指描述车辆系统型式批准的相关参数。

• 标准章节 4.2.8

原文条款：
应具备一个过程，在发布软件升级前，能评估、识别和记录软件升级是否会影响除 4.2.6、4.2.7 之外的任何车辆其他系统（该系统可能与车辆安全和持续运行有关），或是否会增加或更改车辆注册登记时的功能。
​
条款理解：

• 标准章节 4.2.9

原文条款：
应具备一个过程，能将每次软件升级信息通知给车辆用户。
​
条款理解：

3.3 文件和记录要求

• 标准章节 4.3.1

原文条款：
应具备描述车辆制造商进行软件升级的过程以及证明其符合本文件的相关文件。
​
条款理解：
一是应有描述过程的文件，二是应有证明符合性的文件。

• 标准章节 4.3.2

原文条款：
应具备描述型式批准相关车辆系统配置的文件。该文件至少应记录车辆系统的软硬件信息以及相关车辆或车辆系统参数。
​
条款理解：

• 标准章节 4.3.3

原文条款：
当具备软件识别码时，每个软件识别码应具备一个可审核的记录。该记录至少应包括：
a） 描述该软件识别码的编码规则；
b） 描述该软件识别码与型式批准相关车辆系统的对应关系；
c） 描述该软件识别码与型式批准相关车辆系统所有软件版本号的对应关系；
d） 所有相关升级包的完整性校验值。
​
条款理解：

• 标准章节 4.3.4

原文条款：
应具备记录目标车辆并确认其配置与软件升级兼容性的文件。
​
条款理解：
​

• 标准章节 4.3.5

原文条款：
应具备描述每次软件升级信息的文件，该文件至少应记录：
a） 软件升级的目的、时间和主要内容；
b） 软件升级可能影响的车辆系统或功能；
c） b）中车辆系统或功能是否与型式批准有关；
d） 对于 c）中与型式批准有关的车辆系统或功能，软件升级是否影响其符合性；
e） 软件升级是否影响车辆系统的任何型式批准相关参数；
f） 获得车辆制造商内部和/或外部的批准记录；
g） 执行软件升级的方法和先决条件；
h） 确认软件升级能安全可靠执行的证明；
i） 确认软件升级已经成功通过验证和确认程序的证明。
​
条款理解：

3.4 安全保障要求

• 标准章节 4.4.1

原文条款：
应具备一个过程，能保护升级包，合理地防止其在执行前被篡改。
​
条款理解：
本条款是为了保护升级包不被篡改，车辆制造商确保只向车辆推送有效的升级包。具体的保护措施不做限制。

• 标准章节 4.4.2

原文条款：
应保护软件升级全过程，包括发布软件升级的过程，合理地防止其受到损害。
​
条款理解：
“软件升级全过程”是指从将升级包发布到软件升级系统开始，直至完成软件升级执行的整个过程。
在线升级和离线升级的安全防护措施可能不同。

• 标准章节 4.4.3

原文条款：
应具备一个过程，能对被升级软件的功能和代码的合理性进行验证和确认。
​
条款理解：
本条款目的是确保升级包及软件升级过程都经过验证和确认，最大限度地减少升级包中的缺陷（bug）。

• 标准章节 4.4.4

原文条款：
应具备处理软件升级突发事件的应急管理机制。
注：突发事件是指软件升级过程中包括信息安全事件在内的所有可能发生异常的情况，如将升级包发布给非目标车辆。
​
条款理解：
本条款针对软件升级过程中可能突然发生的意外事件（例如，升级包发布给非目标车辆），车辆制造商应具备应急管理机制用于处理相应事件。

3.5 在线升级的附加要求

• 标准章节 4.5.1

原文条款：
对于可能在车辆行驶过程中进行的在线升级，车辆制造商应证明其具备有关过程和程序，以确保该在线升级不会影响车辆安全。
​
条款理解：

• 标准章节 4.5.2

原文条款：
对于需要特定的技能或复杂操作的在线升级，车辆制造商应证明其具备有关过程和程序，以确保只有在专业人员在场或执行该操作的情况下才能进行在线升级。
​
条款理解：

4 车辆要求

4.1 一般要求

• 标准章节 5.1.1

原文条款：
车辆应保护升级包的真实性和完整性，合理地防止其受到损害和无效升级。
​
条款理解：
本条款目的是要求在车辆上实施有效的真实性与完整性保护机制，以确保仅有效的升级包可被下载和执行。

• 标准章节 5.1.2

原文条款：
当车辆存储软件识别码时，车辆应具备更新软件识别码的能力，且每个软件识别码应能通过使用市场上可获取的工具以标准接口（例如，OBD 接口）进行读取。
​
条款理解：
5.1.2 条款针对存储软件识别码的车辆，目的是为了方便监管部门进行读取和检查。

• 标准章节 5.1.3

原文条款：
当车辆未存储软件识别码时，车辆应具备更新软件版本号的能力，且与型式批准相关车辆系统的软件版本号应能通过电子通信接口以标准化的方式进行读取，至少包括标准接口（例如，OBD接口）。
​
条款理解：
5.1.3 条款针对未存储软件识别码的车辆，目的是为了方便监管部门进行读取和检查。

• 标准章节 5.1.4

原文条款：
车辆应保护所存储的软件识别码和/或软件版本号免受篡改。
​
条款理解：
本条款涉及软件识别码和/或软件版本号的安全性，对于车辆上存储软件识别码的，应同时保护软件识别码和软件版本号；对于车辆未存储软件识别码的，应保护软件版本号。

4.2 在线升级的附加要求

• 标准章节 5.2.1

原文条款：
在执行在线升级前，车辆应告知车辆用户有关在线升级的信息，至少应包括：
a) 目的（例如，在线升级的重要性，以及是否与召回、安全等有关）；
b) 对于车辆功能的任何更改；
c) 完成在线升级的预期时长；
d) 执行在线升级期间任何可能无法使用的车辆功能；
e) 有助于安全执行在线升级的任何说明。
​
条款理解：
目的是车辆用户在执行在线升级前被告知，并确保车辆用户获得执行在线升级所需的所有必要信息。

• 标准章节 5.2.2

原文条款：
在执行在线升级前，车辆应得到车辆用户的确认。
​
条款理解：

• 标准章节 5.2.3

原文条款：
在执行在线升级前，车辆应确保满足先决条件。
​
条款理解：

• 标准章节 5.2.4

原文条款：
在执行在线升级前，车辆至少应确保有能完成在线升级（包括可能恢复到以前版本或使车辆进入安全状态）的足够电量。
​
条款理解：
目的是保障车辆具备完成在线升级所需的电量，包括在升级失败后恢复到以前版本/使车辆进入安全状态所需的电量。
本条款无技术路线限制，电量是支撑软件升级最直接的能源，既适用于电动车也适用于燃油车。

• 标准章节 5.2.5

原文条款：
当执行在线升级可能影响车辆的安全时，在执行在线升级时，车辆应通过技术措施确保安全。
​
条款理解：
本条款的目的是要求车辆制造商对执行在线升级是否影响车辆安全进行评估和识别，并通过技术手段确保车辆安全。

• 标准章节 5.2.6

原文条款：
当执行在线升级可能影响驾驶安全时，在执行在线升级时，车辆至少应：
a) 确保车辆不能被车辆用户驾驶；
b) 确保任何影响成功执行在线升级或影响车辆安全的车辆功能不能被车辆用户使用。
​
条款理解：
本条款的目的是要求车辆制造商对执行在线升级是否影响驾驶安全进行评估和识别。对于影响驾驶安全的在线升级活动，应采用技术手段确保车辆在执行在线升级过程中不能被驾驶，同时为了保障车辆安全和软件升级成功执行，还可能限制部分车辆功能的使用。

• 标准章节 5.2.7

原文条款：
在执行在线升级时，车辆不应禁止车辆用户从车内解除车门锁止状态。
​
条款理解：
本条款目的是要求车辆在执行在线升级的过程中，至少保障车辆用户可以从车内解除车门锁止状态。避免紧急情况下，车内用户无法下车。

• 标准章节 5.2.8

原文条款：
在执行在线升级后，车辆应：
a) 告知车辆用户在线升级的结果（成功或失败）；
b) 若成功，告知车辆用户所完成的更新，并及时更新车载电子版机动车产品使用说明书（如有）；
c) 若失败，告知车辆用户处理建议。
​
条款理解：
本条款目的是要求车辆制造商在在线升级执行后，应将在线升级的结果及附加信息告知车辆用户。
对于具有车载电子版机动车产品使用说明书的，应及时更新手册内容避免对车辆用户造成误导。

• 标准章节 5.2.9

原文条款：
当在线升级失败时，车辆应确保及时将车辆系统恢复至以前的可用版本或将车辆置于安全状态。
​
条款理解：
本条款的目的是要求车辆制造商对升级失败的情况进行管理，可以考虑及时恢复到以前可用的版本，如不能确保恢复到以前可用的版本，至少应该确保车辆处于安全状态。
“安全状态”由车辆制造商具体定义并证明其有效性。

• 标准章节 5.2.10

原文条款：
对于 5.2.1 和 5.2.8，车辆应通过车辆系统将信息告知车辆用户。若因车辆硬件原因无法通过车辆系统告知车辆用户，车辆制造商应证明其具备合理技术措施实现信息告知。
​
条款理解：
由于车辆开展在线升级时，直接影响车辆上驾乘人员的生命安全，所以对于在线升级前后的用户告知，应优先通过车机、仪表屏幕等车端可视化的方式直观告知车辆上的驾乘人员。
对于不具备显示屏等硬件设施的车辆，无法实现在车端告知用户，车辆制造商应证明其具备合理技术措施确保及时地告知车辆用户有关升级的相关信息。

5 同一型式判定

5.1 同一型式判定要求

5.2 同一型式判定逻辑

5.3 同一型式判定情形

5.4 同一型式判定要求解读

5.4.1 直接视同判定条件（在线/离线）

视同规则：不一致则不能视同

5.4.2 直接视同判定条件（在线）

视同规则：不一致则不能视同

5.4.3 测试验证后视同判定条件（在线/离线）

视同规则：若能被软件升级的ECU新增， 则补充新增ECU的试验项。

6 型式认证流程

6.1 拆分线

6.2 串联线

7 软件升级合规文档

7.1 文档收集背景

在GB44496标准中，规定了车辆每次软件升级都需要有记录软件升级相关信息的文档，该文档即软件升级合规文档。对于国内市场，车企应在每次软件升级前，正确填写软件升级合规文档并按标准要求存档，以确保车型合规上市销售。

软件升级合规文档的主要目的，就是为了记录或说明，本次车辆软件升级功能变更与法规之间的关系。例如，变更内容是否符合法规要求，软件升级后，车辆功能是否仍然满足法规标准，软件变更是否影响原有的车辆型式批准等。

以下是在软件升级合规文档中需要（或可以）收集的信息条目的通用设计，可以满足标准要求的大部分条款（未涉及的条款可能需要单独的文件记录）：

1. 基础参数记录
   1. ECU 简称
   2. ECU 全称
   3. ECU 地址
   4. ECU GBSWIN
   5. ECU 硬件版本信息
   6. ECU 软件版本信息
2. 升级评估记录
   1. 软件升级的目的
   2. 软件升级的主要内容
   3. 软件升级可能影响的车辆系统或功能
   4. 软件升级是否会影响任何车辆其他系统（与车辆安全和持续运行有关）
   5. 软件升级是否会增加或更改车辆注册登记时的功能
   6. 软件升级影响的车辆系统或功能是否与型式批准有关
   7. 其中与型式批准有关的车辆系统或功能，软件升级是否影响其符合性
   8. 车辆型式批准结果是否不再适用软件升级后的车辆
   9. 软件升级是否影响车辆系统的任何型式批准相关参数
   10. 软件升级获得车辆制造商内部和/或外部的批准记录
   11. 执行软件升级的方法和先决条件
   12. 确认软件升级能安全可靠执行的证明
   13. 确认软件升级已经成功通过验证和确认程序的证明

7.2 文档管控流程

• 管控范围：所有支持SWDL的ECU
• 管控开始时间：车型公告认证结束后的第一次软件升级前（公告认证结束，意味着车辆软件正式面向用户，此后所有软件版本均为市场版本）
• 管控结束时间：车型停产
• 管控流程（在每次软件升级阶段前）：
  1. 控制器工程师说明ECU软件升级涉及到的功能变更
  2. 功能工程师和法规认证工程师根据功能变更判断是否对相关法规产生影响，是否会导致车辆型式发生拓展2.1 若不会导致车辆型式发生拓展，则直接到流程4；2.2 若导致车辆型式发生拓展，则由法规认证工程师联系拓展认证机构确认拓展认证窗口时间，并在软件升级发布前排期完成拓展认证
  3. 拓展认证完成后，法规认证工程师更新车辆型式批准法规证书
  4. 控制器工程师根据ECU软件升级涉及到的功能变更和车辆型式批准法规证书，填写软件升级合规文档
  5. 法规认证工程师和项目经理签审软件升级合规文档
  6. SUMS工程师存档软件升级合规文档

管控流程参考示例图：