M4-08 车用软件更新的准入与合规（R155/R156·GB 44495/44496·OTA 备案与召回）

课程代码 M4-08　板块 M 项目、质量、成本与合规 ／ M4 标准法规与合规 时长 约 3~3.5 小时（6 讲 + 1 次判定演练）　难度 L2 进阶 适合对象 标准法规／认证／项目管理岗——负责软件与网络安全准入、OTA 备案与软件变更判定的人（必修）；OTA 平台负责人与热管理域控软件／标定负责人（选修，重点读第 3、4 讲，你们负责产出判定所需的技术输入）。 前置 M4-01 热管理相关标准（GB/ISO/SAE）体系 热管理相关标准体系（位阶判断、换版双式、符合性矩阵四列）· K2-04 网络安全与 OTA 安全基础 网络安全与 OTA 安全基础 · 体系外需自备：对 1958 协定框架下型式批准机制、国内《公告》与 CCC 准入制度的基本认识。 本讲义定位 只讲一件事：一个软件版本能不能取得、并且保持型式批准。它不是 OTA 技术课，也不是发布工程课——签名校验、防回滚、SecOC、灰度节奏、回滚门限一律不在本课，去向见「按任务导航」的不覆盖栏。

引言

热管理的人第一次被这门课的问题拦住，通常不是在会议室里，是在一次已经跑了一半的灰度里。

包是干净的：开发做完了，回归过了，签名过了，OTA 平台把它推给第一批车，指标也确实在变好——压缩机启停次数降下来了，投诉在收敛。然后合规岗的同事看到了发布公告，问了一句：这一版你们备案了吗。于是全部批次当天叫停，已经升上去的那几百台车，车上的软件标识和当初申报登记的对不上，接下来两周所有人都在补一份本该在下发之前就写好的材料。

这件事的性质要一开始就说清楚：它不是技术事故，是准入事故。技术链路上没有任何一处报错，也不该报错——签名机制只回答「这个包是不是我发的、有没有被改过」，回归门禁只回答「它跑不跑得起来、有没有退化」。「这一版有没有资格被下发到已获批准的车上」这个问题，技术链路根本没有被要求回答。而它恰恰是本课的全部内容。

⇒ 于是这门课的骨架就是三个连着的判断：

第一，你的组织有没有资格做软件更新这件事。这是体系层。国际侧的形态是两张证书——CSMS（网络安全管理体系）与 SUMS（软件升级管理体系），它们是型式批准的前提条件，不是并行项；国内侧的形态不是照搬证书制，而是强制性国标加公告绑定加备案审批的三件套。第 1、2、3 讲讲这一层。

第二，这一次改动要不要对外走一道程序、走哪一道。这是判档层，也是本课重心。四档结论——内部留档／备案后方可下发／涉安全变更审批通过后放量／构成召回的实施方式——每一档的判据链、要办的事、要留的证据。第 4、5 讲讲这一层。

第三，同一次改动在不同市场落在不同档时，怎么排、怎么举证。这是多市场层。第 6 讲讲这一层。

三层之间有一条贯穿的钉子，本课把它立在最前面，后面每一讲都要坐实一次：

钉子①：硬件准入是一次型式批准即完结，软件准入是发布后仍然持续的义务。

这句话在 M4-01 热管理相关标准（GB/ISO/SAE）体系 第 8 讲写下过，本课接的就是这句话后面的执行链。它为什么值得当钉子，是因为它决定了组织的形状而不只是流程的长短：一次性的事可以在项目上设一个里程碑，做完就散；持续的事必须有常设的角色、常设的记录、常设的判定动作。绝大多数把 OTA 合规做砸的团队，砸的不是某一次判断，是没人把这件事当成一件持续的事。

还有一根钉子在第 5 讲收，这里先立住，因为它是本课最容易被误用的一处：

钉子②：软件变更的四档结论，与硬件变更的四档结论，输入同构、结论不通用。

两边判定的入口问题确实是同一个——动没动被考核参数、动没动型式批准的举证基础；但落下来的档位名、要办的事、办给谁、多久办完，两套完全不同。M4-06 热管理强检项的认证与送检执行实务：准入链时序、送检状态冻结、检测机构与失败返工 第 5 讲那四档（不影响／文件性变更／扩展并补测／重新型式批准）是硬件侧的；本课这四档是软件侧的。把硬件那张表直接套到软件上，是项目上真实发生频率最高的一类误用，M4-03 安全法规（可燃工质/高压/热失控）合规 已就此写过明文警告，本课第 5 讲把两张表并排画出来，让这个错在视觉上就成立不了。

六讲的排法。第 1 讲立位阶与责任主体，把「工程标准」和「体系证书」这一对拆开——这是整条链的入口，拆错了后面全错。第 2 讲讲证书怎么拿、怎么保，以及责任怎么靠合同下沉到热管理域控 Tier1。第 3 讲转到中国口径的车型准入侧：两个强标的分工、两档实施日、公告与软件版本的绑定。第 4 讲是中国口径的每次下发侧，也是本课重心：备案、涉安全变更审批、以及 OTA 与召回的关系。第 5 讲交付本课的主产出物——一张软件变更准入判定表，含三个热管理专属落点的判据链演练。第 6 讲收到多市场：软件版本—市场—批准号矩阵，以及 SUMS 证据包怎么挂进认证包。

本课的数字纪律，先说在前面。这门课通篇不给条款级数值：证书有效期与监督周期、两个强标的分档实施时点、备案与涉安全变更审批的材料清单与办理时限、四档判定的具体阈值，本课一律标「待核」，不填。理由不是谨慎，是这些量的正确来源只有一处——现行有效版的原文与主管部门现行发布的文件；讲义里写一个数，读者拿去用，等于把一份会过期的东西钉死在一门不会自己更新的课上。⛔ 凡本课出现「待核」二字的格子，都要你自己去取原文，取不到就标着待核往下走，不许凭印象或按上一款车类推填。文件的版次一律以现行有效目录为准，⛔ 本课不钉死年份。

按任务导航

你手上的任务	直接读	还要顺手做的
项目刚立项，要排认证节点，想知道软件侧要提前多久动	第 2 讲 2.2「前置不是并行」	第 1 讲图2 的对照，把「持续义务」写进项目组织表
一个 OTA 包明天要放灰度，要判它能不能发	第 5 讲判定表 + 第 4 讲 4.1 备案时点	第 4 讲 4.4 的留痕字段，先把记录格式定下来
改了电池热事件报警阈值，不确定算不算涉安全变更	第 5 讲 5.3 三个热管理落点	技术输入去 M4-03 安全法规（可燃工质/高压/热失控）合规 取，本课只判要不要走审批
车型要出口，一版包要发到三个市场	第 6 讲 6.2 版本矩阵	第 6 讲 6.3 拆包与最严市场两种排法
体系审核下个月来，要准备 SUMS 证据包	第 2 讲 2.4 五块骨架	第 6 讲 6.4 证据怎么挂进符合性矩阵
Tier1 要签技术协议，不知道该写哪几条软件条款	第 2 讲 2.6 合同四条	第 2 讲 2.7 证据缺口的后果落在谁身上
有人说「悄悄修一版就不用召回了」	第 4 讲 4.3	第 4 讲图8，把两端关系画给他看

⛔ 本课不覆盖 · 栏一（每样带去向）：OTA 技术安全链路（签名校验、防回滚与安全版本号、SecOC、HSM、安全启动、差分完整性）→ K2-04 网络安全与 OTA 安全基础；发布工程（灰度放量节奏、观察窗、回滚门限、参数锁定分级、车队数据统计显著性、双分区刷写）→ K7-02 软件定义热管理与 OTA 迭代，本课只向它输出「判档状态」这一个门禁入参；E/E 架构演进与软件定义整车叙事 → N5-02 软件定义热管理与整车 OTA 演进；软件版本号语义、基线与配置管理工程实践 → K4-04 软件版本、配置与变量管理，库侧标定资产的版本与分支 → K6-05 标定数据管理与版本控制；标准位阶判断方法、标准地图、符合性矩阵四列结构与证据链呈现方法本身 → M4-01 热管理相关标准（GB/ISO/SAE）体系，本课只引方法、只往矩阵里挂行；冷媒可燃性、电池热失控、高压安全三条线的技术判据 → M4-03 安全法规（可燃工质/高压/热失控）合规，本课只把它们当判定演练的技术输入；除霜视区作图与融霜热量核算 → C5-01 前风窗除霜除雾法规与性能设计，本课只取「除霜标定属公告被考核参数」这一面；硬件强检的送检执行、状态冻结、检测机构比选与硬件变更四档 → M4-06 热管理强检项的认证与送检执行实务：准入链时序、送检状态冻结、检测机构与失败返工；内部重验范围与量产断点切换 → M2-06 量产阶段变更控制：4M 变更申报、再验证范围判定与量产断点切换；召回的工程触发判据与在役失效数据分析 → M2-05 售后保修与在役失效数据分析：从索赔表读出真实故障率并反馈设计；交付物形态、DIA 与联合验证签署 → K4-09 热管理控制软件的跨企业交付边界：交付物形态、DIA/SEooC、权限分级与联合验证签署；预期功能安全与 AI 件安全论证 → K2-05 预期功能安全（SOTIF/ISO 21448）与 AI 件安全论证在热管理的落法；汽车数据安全、个人信息保护与数据出境这条合规线 → 制度侧 N6-01 预测性热管理的车云数据生态与产业路径、车端落地判据 K7-04 车队数据回流的车端实现：信号表定义、事件抓帧与带宽/存储预算。

⛔ 本课不覆盖 · 栏二（真正不给的数，且没有别处能替你给）：① 一切条款级内容与数值——CSMS／SUMS 证书的有效期年限与监督周期、两个强制性国标的分档实施时点、OTA 备案的材料清单与办理时限、涉安全变更审批的触发判据与时限、软件识别号的绑定范围与变更条款，本课未独立取得可核对的现行原文，因此只写「这份文件是什么、它管哪一段、去哪查」。② 某一次改动落哪一档的最终结论——判定表本课给的是骨架与填法，格子里的依据必须由你逐条从现行有效版原文取回，允许标「待核」。③ 某一家技术服务机构或认证机构的资格结论——资质与采信规则会滚动变化，判据只能来自主管部门与认可机构的现行公示，⛔ 不来自任何讲义。

第 1 讲　体系证书 vs 工程标准：这条准入线的位阶与责任主体

1.1 入口：为什么第一件事是拆这一对

一个团队做了三年的网络安全工程，按 ISO/SAE 21434 建了威胁分析流程、写了安全概念、做了渗透测试，文件柜是满的。到了申请型式批准的时候被告知：没有 CSMS 证书，申请不予受理。团队的反应通常是「我们明明都做了」。

这句话本身没有错，错的是它回答的不是被问的那个问题。⇒ 两个问题长得很像但不是同一个：

• 你的过程有没有按方法做——这是工程标准回答的；
• 有没有一个被主管机关认可的主体，出具过一份说你行的凭证，而且这份凭证现在还有效——这是体系证书回答的。

第二个问题不能由第一个问题的答案代替，因为它们的签发主体不同。工程标准的符合性是你自己（或你请的第三方）对着标准条款做出的判断；证书是主管机关或它认可的技术服务机构签发的，而且——这一点最常被忽略——它可以被暂停，也可以被撤销。一份可以被撤销的东西，本质上是一段持续的关系，不是一件做完就归档的交付物。

⚠ 说明一句本课与相邻课的分工：R155／R156、CSMS／SUMS 与 GB 44495／GB 44496 之间的映射概览（谁对应谁），K2-04 网络安全与 OTA 安全基础 在安全运营与响应那一节已经讲过，本课⛔ 不重讲概览。本讲做的是概览之下的三件事：成对拆解、责任主体、位阶排序。

1.2 成对拆解一：ISO/SAE 21434 与 UN R155

ISO/SAE 21434 是道路车辆网络安全工程的工程标准。它给的是「网络安全工程该怎么做」——从概念阶段的威胁分析与风险评估，到开发、生产、运行、退役各阶段的活动与工作产品。它的产物是过程能力与过程证据。

UN R155 是要证书的法规。它要求的是车辆制造商具备并运行一套网络安全管理体系（CSMS），并由主管机关或技术服务机构审核后签发 CSMS 证书；这张证书是相关车型型式批准的前提。

⇒ 两者的关系可以写成一句可以当场检查的话：21434 的过程符合性是 CSMS 审核的输入，不是它的替代品。

这句话有一个立刻可用的推论：做 21434 的时候就要按「将来要被审核」的形态来做。同样一份威胁分析，写成一份内部技术报告和写成一份带责任人、带评审记录、带版本、带追溯关系的受控文件，技术内容可以一模一样，但前者在体系审核时补不出来。⚠ ⛔ 不要在项目后期才把技术文件「整理成」体系证据——整理这个动作本身留不下当时的时间戳，而审核看的恰恰是你当时是不是这么做的。

1.3 成对拆解二：ISO 24089 与 UN R156

同样的形状，换一条线。ISO 24089 是道路车辆软件更新工程的工程标准，它给的是软件更新工程的过程要求；UN R156 是要 SUMS 证书的法规。

这一对比上一对多一层实用价值：ISO 24089 的过程要求可以直接拿来当 SUMS 证据包的组织骨架。也就是说，你不必自己发明一套证据的分类方式——按它的过程要求分块，审核时的对照成本最低。⚠ 但要写死一句：它本身不是任何市场的准入凭证。拿着一份 ISO 24089 的过程符合性声明去申请型式批准，与拿着一份 21434 的声明去申请，结果是一样的：不予受理。

⚠ 这两个国际工程标准的现行版本、与之配套的实施安排，⛔ 本课不写年份，一律以现行有效目录为准，引用前须核原文。

1.4 责任主体：只有一个，而且它不是 Tier1

这一条要在开场就钉死，因为它决定了合同该怎么签、风险该由谁定价。

证书与型式批准挂在整车（持证）企业名下。热管理域控 Tier1 在这条链上交的是过程证据与技术输入，不是证书。被暂停或被撤销的，是整车企业的证书与它名下的车型批准——⛔ 不是供应商的资质。

⇒ 由此得到一条与 M4-06 热管理强检项的认证与送检执行实务：准入链时序、送检状态冻结、检测机构与失败返工 完全同口径的推论：「供应商说不影响」不构成免判理由。供应商的判断是判定的输入之一，它替代不了那次判定本身；判定要由持证企业做、留记录、承担后果。

⚠ 在 Tier1 一侧还有一条方向相反的推论，热管理域控软件负责人尤其要记住：你交出去的那句「这一改不影响准入」，会被整车企业写进判定记录，并据此不办任何对外程序。所以交这个结论时必须写清三件事——你判的是哪几个参数、依据是什么、你没判哪些。一句不写射程的「不影响」，是把整车侧的风险整段接到自己身上。

1.5 位阶排序：先排位阶，再谈达标

判一份文件对本项目有多硬，方法在 M4-01 热管理相关标准（GB/ISO/SAE）体系 第 1 讲（谁发布 → 它本身是不是强制 → 有没有被强制文件、准入链或合同引用），本课⛔ 不重讲方法，只把本课射程里这几份文件按那套方法排一次结果：

层	本课射程内的文件	不合规的后果落在哪
行政法规／规章	缺陷汽车产品召回相关的行政法规及其实施办法；道路机动车辆生产企业及产品准入管理相关部门规章；OTA 备案相关的主管部门现行发布文件	无法准入、被责令召回、公告受影响
强制性国标	GB 44495（整车信息安全技术要求）、GB 44496（软件升级通用技术要求）	型式批准／公告过不去
国际法规（1958 协定框架）	UN R155、UN R156	相应市场的型式批准过不去
国际工程标准	ISO/SAE 21434、ISO 24089	过程能力被质疑，但它本身不是准入门槛

⚠ 表里有一件事值得单独指出来，它也是 M4-01 热管理相关标准（GB/ISO/SAE）体系 那根钉子在本课的一次坐实：最上面那一层没有标准号。沿着「标准」这条线索去枚举本课的合规要求，行政法规与部门规章整类不会出现——而恰恰是它们决定了「你要不要召回」「你的公告还在不在」。⇒ 建软件准入的要求清单时，第一步不是查标准库，是先问「这件事的准入侧归哪个主管部门管、它现在发过哪些文件」。

⚠ 关于文件名的一处已知不一致，本课明写出来而不替它定名：仓内两处对准入管理那份部门规章的称呼不一致（一处作《道路机动车辆生产企业及产品准入许可管理办法》，一处作《道路机动车辆生产企业及产品准入管理办法》）。本课一律标待核——⛔ 引用前请自行核对主管部门现行发布的准确文件全称与文号，不要照抄任何讲义里的名字。

1.6 钉子①落地：一次批准即完结 vs 发布后持续义务

硬件那条线的形状是这样的：定型 → 冻结送检状态 → 送检 → 拿报告 → 取得批准 → 生产一致性监督。批准这件事有一个明确的完成时刻，之后是监督，而监督的对象是「你造的车还是不是当初批的那台」。

软件这条线没有那个完成时刻。取得批准只是开始：证书要监督、要换证；每一次下发都可能重新触发判定；每一次判定都要留下可被追问的记录。⇒ 它在项目管理上的形态不是里程碑，是一条常设的运行流程。

这一讲的三句话。① 工程标准与体系证书的差别在签发主体与举证形态，前者是后者的输入而不是替代；② 责任主体是持证的整车企业，Tier1 交证据、不交证书，而 Tier1 交出的每一句「不影响」都要带射程；③ 软件准入没有完成时刻，它的组织形态是常设流程而不是里程碑。