第四章　车辆网络安全与软件更新

4.1　从交付时的合规，延伸到车辆在用期间的合规

车辆网络安全和软件更新管理涵盖管理体系、车型技术要求及车辆在用期间的持续责任。它们要求制造商能够说明：车辆依赖哪些电子系统、软件和外部服务，可能受到什么威胁，采取的措施是否有效，以及车辆交付后如何识别新风险、控制软件变化并维持已经证明的符合性。

UN R155围绕车辆网络安全及网络安全管理体系展开。网络安全管理体系，即Cyber Security Management System，简称CSMS，是制造商识别、评价和处理车辆网络安全风险的组织过程、职责和治理安排；具体车型还需证明这些过程已落实到其电子电气架构、接口、供应链、保护措施和验证活动。UN R156围绕软件更新及软件更新管理体系展开。软件更新管理体系，即Software Update Management System，简称SUMS，管理软件识别、目标车辆、更新兼容性、批准影响、执行条件和更新记录；具体车型则需具备相应的安全更新能力。[5，第2、6、7段；6，第2、6、7段]

两项法规的交集，是把网络安全整改落实为受控的软件变化；差别在于，R155回答“风险是否被充分识别和处理”，R156回答“更新是否经过正确评估，并安全、准确地部署到允许接收的车辆”。安全网关、CSMS、SUMS、网络安全测试及软件更新影响评估分别具有相应的证明对象；制动软件变更的覆盖关系仍由具体技术证据确定。

本章以新M、N、O类车辆的型式批准为主线。燃油、混合动力（HEV）、插电式混合动力（PHEV）、纯电动（BEV）及氢能车辆均按实际电子系统和软件能力判断，不能仅因动力形式不同而推定豁免。GB无限系列、M1/N1中批量以及多阶段和专用车辆在相应小节分别处理。国家小批量和单车批准的项目要求、豁免及等效接受不在本章作通用结论，应接入第一章中已选定的具体批准路径；本章的无限系列日期表不得直接套用到IVA。

4.2　GB与NI的法律基线与实施安排

4.2.1　GB已经实施的要求及后续注册节点

英国《The Road Vehicles (Type-Approval) (Amendment) (No. 3) Regulations 2025》，即SI 2025/1110，自2025年11月13日起生效。该法修改英国同化版本的Regulation (EU) 2018/858及2020/683，将R155、R156纳入GB型式批准要求，并在2018/858附件XII中规定适用类别、版本和分阶段实施日期。这里的法律对象是英国同化版本，不能把欧盟原法的修订日期直接用作GB日期。[1，第1—3条]

GB无限系列清单中，R155适用于M1、M2、M3、N1、N2和N3；R156列入上述类别及O1—O4。与此同时，R156自身的范围是允许软件更新的车辆，故“没有OTA”不是不适用的充分理由：支持维修站有线刷写的车辆仍可能属于其范围。反过来，R155的UN原法规范围包含装有至少一个电子控制单元的O类车辆，并不意味着SI 2025/1110已经对全部O类车辆强制实施R155。[1，第2(3)、2(5)条；5，第1段；6，第1.1段]

表4-1　GB的R155／R156实施事件

表中日期和事件取自英国同化版2018/858附件XII表3、表4；适用时应连同附件II中相应车型、专用车项目及例外使用。[1，第2(5)(c)条]

截至本章基准日，2026年6月1日的新型式节点已经到达。因此，普通完整车或基础车的新GB申请不能再把R155／R156列为“后续考虑”。已有型式也不能仅凭批准签发时间早，就推定其后生产、注册的车辆始终不受新要求约束；需要将型式批准日期与表4-1中实际注册事件分开判断。制造日期、离港日期或车辆到港日期，均不能替代这里的注册触发条件。

GB中批量也不是两项要求的当然豁免。SI 2025/1110同时在附件II第I部分附录1的M1、N1中批量表中加入R155、R156。专用车则需要查对应表格：例如移动式起重机的R155行明确包含完整车情形不适用的注记，不能把这项特定例外扩展为所有专用车豁免，也不能把“专用用途”与法律上的Special Purpose Vehicle分类等同。[1，第2(3)(a)(ii)、2(3)(b)条]

4.2.2　NI的独立实施时间表

VCA明确说明，北爱尔兰的车辆型式批准继续适用相应欧盟法律及其修订；EU批准可以用于NI，UK(NI)批准采用“n11”标识，由VCA签发，但UK(NI)批准不因此成为可在欧盟使用的EU批准。GB、EU和UK(NI)批准属于分别维护的框架。[4]

按VCA于2026年5月22日更新的网络安全与软件更新执行页面，EU无限系列M、N类的R155新整车型式节点为2022年7月6日，既有型式节点为2024年7月7日。R156的时间安排不同：页面列明2024年7月7日的新整车型式节点，并对2022年7月6日和2026年7月7日两个节点附加“制造商在注册后实施影响型式批准特性的软件更新”的条件；新完成车列至2029年7月7日。[3，“Application Dates”]

这些是主管机关给出的执行摘要，不宜脱离其脚注重写成“2024年所有英国新车同时强制R155／R156”。尤其是EU小批量、专用车以及R156注册后更新条件，需要结合具体路径的欧盟法律表格逐项解释。各路径的完整适用性仍依据对应法律表格确定。

对于同平台同时进入GB和NI的项目，应分别建立批准基线和车辆适用清单。硬件和部分测试可以共用，但共用的依据应是相同的系统边界、软件状态、风险假设和证据覆盖，并由实际配置及对应资料支持。全球软件推送的放行结论分别覆盖各目标市场。

4.2.3　国际修订生效与GB版本接受程序

SI 2025/1110在附件XII表1写入的是R155和R156的“Original version”。这应与UN法规的原始系列、后续补篇、较新修订系列及国家接受规则分别核对，相应记录标明实际采用的完整版本。[1，第2(5)(a)条]

R156的国际修订状态已经发生变化。联合国保存人通知C.N.237.2026.TREATIES-XI.B.16.156确认，2025年12月4日通知的修订自2026年6月4日起具有约束力；通知指向ECE/TRANS/WP.29/2025/142及会议报告ECE/TRANS/WP.29/1188第78(c)段的调整。相应工作文件属于R156新01系列修订。因此，截至本章基准日，不能仍将01系列全部描述为尚未通过的提案。[7]

但国际生效、签发或接受某一系列的UN批准，以及GB附件明确要求的系列，是三个不同问题。以下RXSWIN和更新程序的具体条款解读，以文中注明的R156原始系列文本为基线；不得将其直接当作01系列的完整差异分析。拟在2026—2030年取得新批准、扩展现有批准或改用01系列证据的项目，还需要将01系列最终文本、过渡条款与目标批准机关的接受条件纳入本项目法规基线。

4.3　体系证书、车型批准与整车批准的证明范围

4.3.1　四层证据链

CSMS、SUMS证书证明制造商的相应管理体系经过评估；R155、R156车型批准证明特定车辆型式符合相应法规；GB或UK(NI)整车批准进一步确认该型式所需的全部项目已满足相应框架；每辆车的实际配置，则必须能够通过车辆识别代号（Vehicle Identification Number，VIN）等记录回溯到获准状态。四层证据分别对应管理体系、车型和整车层面的要求。[5，第3、5—7段及附件2、4；6，第3、5—7段及附件2、4]

图4-1　从组织能力到在用车辆的证据关系

制造商CSMS／SUMS及其有效证书

↓ 将体系过程应用于明确的车型、供应商和软件范围

车型风险分析、保护措施、更新设计及验证证据

↓ 由批准机关／技术服务机构审查并按要求验证

R155／R156车型批准及整车型式批准中的项目记录

↓ 通过生产和更新配置控制落实到单车

VIN对应的硬件、软件、RXSWIN及更新结果

↑ 在用风险、维修变更和事件反馈重新进入体系与车型评估

一个集团内多品牌使用相同开发团队，并不自动证明每个制造商主体均在证书范围内。相同营销车型使用不同网关、通信模组、移动应用或云端接口，也不自动属于同一网络安全型式。R155第2.1段关注制造商型式名称及与网络安全相关的电子电气架构和外部接口的实质特征；R156第2.1段关注与软件更新过程有关的设计实质特征。项目应据这些边界组织车型族和差异说明，并建立与销售配置表之间的对应关系。[5，第2.1段；6，第2.1段]

对于已经持有其他市场R155／R156批准的制造商，VCA说明可通过revision程序将现有批准加入GB批准，并建议结合正常申请计划办理。该安排为既有证据提供行政衔接，GB整车批准仍依相应程序办理。实际仍需核对制造商主体、车型覆盖、系统和软件差异、批准状态及GB适用版本。[2]

4.3.2　证书有效期及到期后的法律后果

R155第6.7段规定CSMS证书最长有效期为三年，第6.10段要求制造商及时申请新证书或延长有效期，以便在原证书到期前完成评估。其第6.11段进一步规定，CSMS证书到期或撤销，应作为相关车型批准的变更处理；当批准条件不再满足时，可能涉及撤销车型批准。证书到期涉及体系持续符合性及相关批准的法律状态；撤销与否依规定程序评估决定。[5，第6.7—6.11段]

R156原始系列第6.6段同样规定SUMS证书最长三年，但第6.10段明确：已有车型批准不会仅因制造商SUMS证书到期而失效。这不等于制造商可以停止运行SUMS，或在体系不符合时继续任意更新。体系持续符合、证书维护、新申请和变更仍分别受到第6、7、8、9段约束。[6]

企业管理台账应至少区分体系证书有效期、车型批准状态、年度监测报告、生产一致性安排和每次软件发布。将它们合并成一个“认证有效至某日”的字段，会掩盖不同的维护责任。

4.3.3　ISO标准、功能安全与数据保护的边界

ISO/SAE 21434:2021提供道路车辆网络安全工程的生命周期框架，适用于相关电子电气系统及其接口。ISO 24089:2023及其2024年修订涉及软件更新工程的组织和项目活动，包括更新包与部署所依赖的系统。它们可帮助构建R155／R156证据，但ISO符合性声明、审核或认证不能替代UN法规要求的体系符合性证书及车型批准。[8；9]

功能安全与网络安全具有不同的风险对象，分析过程相互衔接。功能安全关注故障行为引出的不合理风险；网络安全关注威胁利用薄弱点导致的危害。一个制动控制器可以在通常故障条件下进入预定降级状态，却仍可能存在未经授权改变标定的风险；一次针对安全漏洞的补丁，也可能引入影响实时控制或故障反应的变化。工程上应建立两类分析之间的接口，分别保留相应风险的评价依据。[8]

数据保护也不因取得R155批准而完成。R155第1.3段明确保留隐私和个人数据保护法律的适用；ICO的数据保护原则还涉及合法、公平、透明、目的限定、最小化、准确性、保存期限和问责。为监测攻击采集车辆日志，需要同时解释为何采集、涉及哪些个人数据、谁可以访问以及保留多久，不能仅以“用于网络安全”概括全部处理依据。联网数据的具体法律安排归入第十四章。[5，第1.3段；10]

4.4　管理体系的构成与持续运行

4.4.1　CSMS的项目实施与持续运行

R155第7.2段要求CSMS覆盖开发、生产和停止生产后的阶段，并具备风险识别、评价和处理、措施验证、车型测试、风险分析更新、持续监测及事件应对等过程。主管机关不只检查制度是否写出，还要确认相应过程能够用于制造商的实际车辆。VCA的执行说明特别强调体系文件评估和相关人员访谈。[5，第7.2段；3]

在组织层面，应明确谁有权接受残余风险、谁决定暂停发布、谁向批准机关报告，供应商无法及时修复时由谁作出替代处置。网络安全团队提出的整改，必须能够进入软件开发、试验、型式认证、生产和售后流程；否则风险台账虽然更新，实车状态仍可能不变。

4.4.2　SUMS中的软件变化记录与证据关联

R156原始系列第7.1.1段要求制造商能够识别初始及更新后的软件和相关硬件、识别系统依赖、确定目标车辆、确认兼容性、评估型式批准影响，并向主管机关提供相关信息。第7.1.2段要求保存更新前后配置、RXSWIN登记、目标车辆和更新目的、影响、条件及验证等记录。[6]

一次更新的放行依据应能回答：更新对象是谁，为什么需要更新，旧状态是什么，更新内容改变了什么，哪些试验和批准仍可使用，哪些必须补充，发生中断时如何处理，以及如何证明每辆目标车最终处于预期状态。记录范围涵盖软件发布批准、实际部署及相关车辆状态确认。

表4-2　体系层交付物与审核可见的运行证据

表4-2为依照R155第6、7.2段及R156第6、7.1段组织的工程交付建议，并非法规规定的统一文件名称。审核时可以采用不同文件架构，但不能缺少相应过程和证据。[5；6]

4.5　车型层：从资产和威胁推导到措施、测试与残余风险

4.5.1　分析对象与系统边界

车型分析首先需要受控的电子电气架构和接口说明。分析对象不仅包括车内电子控制单元（Electronic Control Unit，ECU），还包括它们与远程服务、移动应用、维修设备、更新平台及供应商服务的交互。R155第7.3.3段要求考虑单个要素、要素间交互及与外部系统的交互；附件5将车内威胁与车辆外部后台相关措施纳入同一分析框架。[5]

可以采用威胁分析与风险评估，即Threat Analysis and Risk Assessment，简称TARA，组织车型证据。TARA是工程方法名称；R155要求的是充分、适当并可追溯的风险分析，而不是强制采用某一家工具、某一种评分公式或统一的“红黄绿”阈值。

分析的起点应是需要保护的资产及其属性，例如制动命令的完整性、更新包的真实性、远程服务的可用性、车辆身份数据的保密性。随后说明受威胁的接口、潜在危害、实施该威胁需要的条件和已有措施，据此判断是否还需降低风险。对附件5威胁判断为不适用时，应保留原因和架构证据；不得整列填写“不适用”而没有系统边界说明。[5，第7.3.3—7.3.4段及附件5]

4.5.2　TARA示例中的措施与验证依据

以下是供本章说明方法的假设M1纯电动车示例。车辆设有车载通信终端（Telematics Control Unit，TCU）、中央网关、维修诊断接口和远程更新平台。风险判断、措施组合和验收条件均为示例，不代表某一真实车型已经测试通过，也不是法规统一指定的设计。

表4-3　假设车型的TARA与验证摘录

对应关系：CS-01主要连接R155附件5更新程序威胁及R156第7.1.3、7.2.1.1段；CS-02、CS-03连接R155第7.3.3—7.3.7段及附件5通信、外部连接和更新相关威胁；CS-04连接R155附件5后台服务威胁和第7.2段持续响应过程。[5；6]

表内每一措施应进一步分解为可执行测试。以CS-01为例，记录中需要明确被测硬件、引导及应用软件版本、信任凭据配置、构造的无效更新类别、预期拒绝阶段、实测日志和恢复结果。只有测试对象与量产状态相符，才能支持该车型的结论。单独提供一份未注明软件版本的渗透测试报告，无法证明交付车辆就是被测对象。

残余风险的可接受性取决于控制措施实施后的综合风险评价。例如软件包签名不能消除凭据被盗后的合法签名滥用；网关隔离不能消除被授权服务本身的过度权限。关闭风险项，应保留措施验证、未消除风险、接受理由、批准人以及重新评估的触发条件。发现新的攻击方法、供应商停服或系统权限变化，都可能使原先可以接受的结论不再成立。

4.5.3　车型验证与批准证据的形成

R155第5.1.1—5.1.2段区分文件审查与车辆验证；技术服务机构或批准机关可以通过抽样验证已声明措施，抽样关注但不限于高风险项。第7.3.6段要求在批准前完成适当且充分的测试。R156第5.1.1段也要求验证车辆实际实现的措施。[5；6]

工程验证计划应把需求、风险项和试验编号相互连接，说明测试在哪个层级实施：代码和组件验证证明局部机制，台架验证证明控制器交互，整车验证证明接口、状态切换和车辆后果，后台或维修环境验证证明外部过程。不同层级可以相互支撑，但不能用局部组件结果省略尚未覆盖的整车集成风险。

测试缺陷应回到相应风险项和软件基线，说明整改版本及回归范围。存在未关闭缺陷时，必须判断它是否使法规要求不再满足；“列入下一版本修复”本身不是符合性结论。对于代表车型覆盖，应明确架构、接口、权限、更新路径和供应商差异，解释为什么一个样车的结果可以代表其他配置；没有共同边界或验证依据时，应增加测试或单独评估。

4.6　供应链证据与车型材料包

R155第7.3.2段要求制造商识别和管理车型的供应商相关风险；第7.2段要求管理对供应商、服务商及内部组织的依赖。VCA说明，R155批准授予车辆制造商，供应商应通过要求传递、协议和信息交付支持制造商。ISO/SAE 21434相关控制器资料可支持R155评估；本车型的接口、权限及后台依赖仍属于具体车型评价范围。[5；3]

对关键供应商，建议约定系统和软件识别、相关风险假设、保护机制说明、验证结果、已知弱点及未解决问题、更新和凭据管理责任、影响评估所需资料、变更通知和停止支持后的安排。软件物料清单（Software Bill of Materials，SBOM）可帮助将新漏洞映射到受影响软件及车辆，但本章引用的法规并未规定一种所有制造商必须统一采用的SBOM文件格式；企业应以可识别、可追溯和可维护为目标选择实现方式。

知识产权保护与批准证据的可核验性需要在提交安排中同时落实。R155第3.2.2段允许对制造商或供应商专有信息作保密处理，同时要求仍须提供足够信息以实施法规检查。受控阅览、保密提交及敏感细节分层，可在保护知识产权的同时支持批准机关核验核心事实。[5]

表4-4　GB信息文件中的车型层资料入口

表4-4依据SI 2025/1110第3(3)条增加的字段编制。法条中12.15.3.1和12.15.3.2具有相同的安全执行说明文字；填报时应保留现行字段，不自行推定其中一项已被立法改写成其他义务。[1]

体系文件、车型信息文件和测试报告应使用一致的车型、架构与版本标识。提交材料的“总目录”最好能够同时标示文件版本、保密等级、批准关联和存储责任，以建立风险项、控制措施与试验结果之间的可追溯关系。

4.7　软件版本、RXSWIN与单车配置的关联

4.7.1　RXSWIN与其他软件、车辆标识的关系

RXSWIN，即RX Software Identification Number，是制造商定义、代表电子控制系统中与有关型式批准相关的软件信息的专用标识。软件发行版本号、控制器零件号、完整性校验数据、RXSWIN和VIN各有不同用途：它们分别识别软件发布、硬件或零件、内容状态、批准相关软件映射以及单辆车辆，不能任取一个字段代替其他字段。[6，第2.2段及第7.1.1—7.1.2段]

在R156原始系列中，第7.2.1.2段采用“车辆型式使用RXSWIN时”的结构；当修改型式批准相关软件导致批准扩展或新批准时，应更新相应RXSWIN。第7.2.1.2.2段还规定了RXSWIN不存储在车上时，制造商申报车辆或单个ECU软件版本及其与批准关系的路径，并要求相关版本可通过标准化电子接口读取。因此，不能将原始系列解释为“所有软件一有版本变化，就必须为整车生成新的统一RXSWIN”。同样，不能以RXSWIN未变化推定软件内容没有变化。[6]

对于01系列项目，不应直接复制原始系列中的条件性表述而不作差异确认；具体采用哪个识别和登记方案，应与该车型的法规系列及有关系统法规相一致。

4.7.2　软件清单与单车实际配置状态

以下清单继续采用假设车型，版本和标识仅供说明，不是实际证书或软件发布记录。其中VCU为整车控制器（Vehicle Control Unit），BMS为电池管理系统（Battery Management System）。

表4-5　假设M1纯电动车的软件配置摘录

清单中的“法规关联”表示需要分析的接口，不表示每个控制器均分别取得相应UN部件批准。完整登记还应包括软件包标识与校验数据、批准及扩展号、相关RXSWIN、适用市场、版本依赖、生产和售后适用范围，以及每个VIN最后确认的软件状态。[6，第7.1.1.2—7.1.1.7、第7.1.2.2—7.1.2.4段]

更新平台仅保存出厂配置不足以满足后续管理需要。维修更换控制器、离线刷写和旧软件恢复，都可能改变车辆状态。工程上应在部署前使用车辆回读或可信维修记录确认必要条件，对状态不明的车辆暂停自动执行，并转入核验流程。无法确认软件与硬件组合时，应记录“状态待确认”，计划推送状态与实际安装状态分别记录。

4.8　软件变化与批准影响评价

4.8.1　软件更新影响评估的范围

R156原始系列第7.1.1.8—7.1.1.10段要求评估更新是否影响已批准系统、系统定义参数、批准参数、原先未有或未启用的功能、资料包和试验覆盖，以及安全和持续运行所需的其他系统。修改标定、开启预置功能或改变参数数据，同样可能触发评估；不应以“没有改源代码”作为不评估的理由。[6]

判断可分三层。首先，确认是否改变与批准相关的资料或性能；其次，逐项判断既有试验、车型划分及批准证据是否仍覆盖；最后，确认应按何种方式通知批准机关、补充资料、取得扩展或申请新批准。制造商承担识别和记录责任，批准机关依法决定其批准是否维持、需补充评估还是调整；技术服务机构的技术意见不能替代批准机关的批准决定。[5，第8.1段；6，第8.1段]

表4-6　更新影响评估与处理示例

表4-6属于法规条款基础上的工程判断路径，不是“某类更新一律免审批”或“一律重新认证”的分类法。

4.8.2　变更通知、批准扩展与软件更新的程序关系

R155第8.1段规定，对影响网络安全技术性能和／或法规所需资料的车型变更，应通知原批准机关；R156第8.1段对影响其技术性能和／或所需资料的变更同样设有通知规则。通知后，机关可以认为变更仍符合既有批准，也可以要求补充评估或报告。故“需要通知”不等于“必然产生新批准号”；“没有改变驾驶功能”也不等于“不涉及R155通知”。[5；6]

R156第9.1.3段要求对制造商过程和决定作周期性核查，特别包括制造商选择不通知某次更新的情况。因此，不通知的决定应同样有书面评估和可审计理由。把所有安全补丁统一归为“无需通知”，或者把全部云端变化视为与车辆无关，都缺少充分依据。[6]

一份实际影响评估至少应形成相互连接的结论：变化内容与边界、受影响系统、批准参数和证据差异、通知与批准动作、软件和RXSWIN处理、验证与部署条件。涉及多个市场时，应分别给出GB、NI及其他市场的放行状态。某市场尚未完成必要程序时，应以目标车辆清单和部署权限隔离，以落实相应市场的部署边界。

4.9　OTA与维修更新的真实性、完整性及安全状态

4.9.1　安全更新的发布、传输与执行控制

空中下载更新，即Over-the-Air Update，简称OTA，是以无线方式传输更新数据。它只是交付方式，不决定更新是否涉及批准，也不使维修站有线更新脱离SUMS。R156第7.1.3段要求保护更新开始前的软件及更新过程，并对软件验证、确认过程提出要求；第7.2.1.1段要求保护更新的真实性与完整性。[6]

真实性关注更新是否来自被授权来源；完整性关注内容是否遭到不当改变；保密性关注内容是否被不当获取。仅有传输加密不能证明软件包来自正确发布者，也不能消除软件在签发前已被替换的风险。工程上可以采用受控发布、凭据保护、包级验证、目标匹配及安全执行等组合，但应说明各措施针对的风险，不宜把特定算法或某种硬件安全模块写成R155／R156对所有车辆统一指定的唯一方案。

发布、下载、安装、激活和结果确认是不同事件。服务器“发送成功”只证明交付链中的一部分；完整的车辆更新记录应能识别下载是否完整、车辆是否满足执行条件、安装及激活是否完成、控制器组合是否一致，以及更新后是否出现需处理的异常。

4.9.2　安装中断：可以恢复旧版本，也可以进入经验证的安全状态

R156原始系列第7.2.2.1.1段允许两条路径：更新失败或中断时恢复此前版本，或者使车辆进入安全状态。OTA失败后的处置路径包括符合条件的版本恢复或经验证的安全状态。恢复旧版本也需要判断其网络安全后果；若旧版本存在正在被利用的严重风险，不能只因其能启动，就把无限期回退作为充分处置。[6]

安全状态必须落到具体功能。例如关键制动软件未完成安装时，车辆可能需要保持不可行驶并提供明确告警和恢复指引；不能仅将显示屏出现错误码作为“已进入安全状态”的证据。多控制器更新还应验证部分成功、部分失败时的接口兼容和车辆后果。

第7.2.2.1.2段要求车辆具有完成更新及可能恢复或进入安全状态所需的足够电能，但没有在该条中给所有车辆统一规定“电量必须大于30%”之类阈值。工程上应根据控制器数量、低压供电、温度、执行时长和恢复能耗设定并验证条件，不能仅凭动力电池的标称荷电状态判断低压系统一定可靠。[6]

表4-7　更新安全状态的工程验证摘录

表4-7为工程验证建议，对应R156第7.1.1.7、7.1.4及7.2.2段；具体测试集合应根据车型风险与更新设计确定。[6]

4.9.3　行驶中更新与用户告知

不能将OTA一律描述为“必须停车”，也不能将后台下载能力解释为任何软件都可以行驶中安装。R156第7.1.4.1段要求评估行驶中实施OTA是否影响安全；当执行更新时行驶可能不安全，第7.2.2.3段要求采取措施防止车辆行驶，并限制可能影响安全或更新成功的功能。需要重新标定传感器等专业或复杂操作时，第7.1.4.2段还要求具备相应人员在场或控制过程的条件。[6]

执行前，应能向用户提供更新目的、功能变化、预计执行时间、暂不可用功能和安全执行指引；执行后，应能告知成功或失败、已实施变化以及需要更新的使用说明。依据为R156第7.2.2.2、7.2.2.4段。告知不能仅写“优化体验”，也不能在安装失败后仍显示为成功。[6]

例如一次涉及制动控制器的更新，可以在用户界面明确写明“安装期间车辆不可行驶；预计时间以本次发布验证结果为准；未完成时请按界面指引联系服务人员”。实际文案必须与经验证的车辆行为一致。法条中的信息提供要求不应被擅自扩展成所有更新都必须采用相同点击同意机制；涉及合同、消费者权利或个人数据的同意问题另行判断。

维修站更新应纳入同一配置和批准控制：工具取得的包应来自受控来源，维修操作须核对车辆和软件状态，必要的标定、复测及回传应成为工单关闭条件。离线更新或故障救援也需要受控的例外程序，不能成为跳过兼容校验、凭据管理和法规影响评估的通道。

4.10　从申请到量产：输入、审查与输出

4.10.1　申请与验证过程

体系证书申请由制造商或其正式授权代表提交；R155、R156第6段规定体系文件和制造商声明，第3段规定车型申请资料，第5段规定批准审查和车辆验证。批准机关承担批准决定；技术服务机构在其相应权限范围内实施评估或测试。咨询公司可以组织申请、协调资料和测试，但不能用自身声明替代制造商责任或机关决定。[5；6]

表4-8　建议按以下链条组织项目

表4-8依据法规程序与VCA执行说明组织；不是对某一机关门户字段、收费或固定办理周期的承诺。VCA已将型式批准询问与申请导向其自助门户，具体提交方式应使用当次受理说明。[3；11；12]

补正记录需要关联具体修改及其证据。每一问题应关联原要求、发现差异、修改文件及版本、补充验证和关闭依据。若补正改变软件状态，应检查此前报告是否仍覆盖；若改变制造商或组织范围，应判断体系证书是否仍适用。

4.10.2　生产一致性与软件配置控制

SI 2025/1110在英国同化版2018/858附件IV增加第5点，要求制造商SUMS和整车型式符合R156。软件更新因此进入生产一致性安排，而不只是售后部门的独立活动。[1，第2(4)条]

工程控制计划应将获准软件、硬件和相关配置落实到生产及维修过程。可采用生产包授权、版本及完整性检查、车辆配置回读、调试权限关闭、异常车辆隔离及刷写重工记录等控制。这里列举的是实现方法，不代表法规统一规定每辆车都必须使用同一套设备或检查频率；频率和覆盖应按风险、工艺和与批准机关确定的安排记录。

GB信息文件与CoC也发生衔接。SI 2025/1110增加R155／R156相关信息字段和CoC第55、56项。该法对旧CoC模板给予“2027年6月1日前制造且有有效GB批准”等条件下的使用安排，但这是模板安排，不能推导出不满足技术注册要求的车辆可以凭旧表格继续注册。CoC字段与电子数据的具体处理见第六章。[1，第3条]

4.11　上市后运营、报告与停止支持

4.11.1　车辆在用期间的持续风险监测

R155第7.2段要求持续监测，并明确将首次注册后的车辆包括在内。第7.4.1段要求制造商至少每年一次，或在相关情况下更频繁地，向批准机关或技术服务机构报告监测结果、新网络攻击相关信息、措施持续有效性及采取的额外行动。年度报告与漏洞响应分别履行；需要响应的威胁和漏洞按法规要求在合理时间内处理。[5，第7.2.2、第7.4段]

建议建立产品网络安全事件响应职责，并使其与型式认证、售后、产品安全和数据保护团队协同。对每项新信息，应先判断可信度及是否存在本车型相关组件，再映射到软件和车辆范围，分析危害与暴露情况，决定临时遏制、补丁、维修措施或其他整改，并验证最终效果。不能把公共漏洞严重度直接等同于整车风险，也不能因尚无客户事故就认定无需处置。

R155所述年度报告和合理响应时间，不等于所有网络安全事件统一适用“72小时向VCA报告”。事故、车辆安全缺陷、个人数据事件及其他网络义务可能具有不同规则和对象；各项通报时限分别依据其所属制度确定。涉及安全缺陷和召回时，应与第十三章的相应流程联动。

4.11.2　安全事件的处置过程与关闭证据

企业内部可将过程组织为“信息接收—受影响范围确认—风险决定—临时措施—永久整改—批准及部署—效果复核”。各阶段分别形成接收记录、车辆影响结论、软件修复结果、部署记录及车辆整改确认。对于长期离线、客户拒绝执行或维修后状态不明的车辆，应保留未完成原因和替代处置，并纳入整改状态统计。

年度报告的工程组织建议包括：报告期间、车型和车辆范围、主要监测渠道、发现与确认的问题、风险及响应决定、措施有效性、未完成整改车辆、供应链问题、体系变化和下一步行动。报告中引用的车辆数量、软件状态和完成率，应能回到可审计的记录；向机关提交的范围和频率再按具体受理安排执行。[5，第7.4段]

4.11.3　证据保存期与支持期不同

R155第2.7段将停止生产后的阶段延伸至该型式车辆不再运行；第7.2.2.1段要求CSMS覆盖该阶段。因此，停产、保修期结束或车型退出某个市场，不当然终止相应的网络安全管理过程。[5]

R155第3.3段及R156第3.7段对批准资料和制造商保留供检查资料规定了停止生产后至少十年的可用性要求。资料保存期与软件更新支持期各有适用依据。生产一致性记录另有具体安排，也不应把不同条款中对保存时间的表述混为一谈。[5；6]

制造商应在车辆开发和采购阶段明确后台、凭据、漏洞信息、更新工具及维修恢复能力的长期安排。终止某项云服务前，至少需要分析其对车辆安全、网络安全、已批准功能、更新能力和消费者承诺的影响。工程上可以通过迁移服务、降低外部依赖或提供替代更新渠道处理，但结论必须由实际功能和风险决定；一纸停服通知不能替代技术和法律评估。

4.12　多阶段车辆、专用车与挂车的处理

4.12.1　基础车证据的利用条件与后续阶段责任

多阶段制造中，基础车制造商应提供与后续阶段相关的系统边界、可用接口、允许的连接和软件变化、更新约束及风险假设；后续阶段制造商应说明新增设备、线路、网关、远程服务和控制策略如何影响这些条件。这是依据R155对系统交互与供应链风险、R156对依赖和更新兼容性的要求作出的工程分工，不意味着后续阶段只需引用基础车证书编号即可完成证明。[5，第7.3段；6，第7.1.1段]

例如在N类底盘上增加车身控制器和远程作业平台，可能新增后台到车辆的访问路径，改变诊断和升级权限；上装控制器自身不直接控制行驶，也不足以排除网络安全影响。相反，完全独立、没有共享通信或更新接口的设备，可以在明确边界和证据下论证较小影响，相应责任与影响结论仍需具体证据支持。

各阶段的交付建议至少覆盖接口和架构版本、基础车软件基线、允许配置及限制、相关风险和测试、更新责任、对方变更通知要求以及最终车辆的版本确认。最终阶段放行前，应将基础车当前状态而非最早交付状态纳入评估，防止基础车已更新、上装兼容性仍按旧版本判断。

4.12.2　跨注册日期的假设案例

假设一辆普通N2完成车拟于2027年7月在GB首次注册，不属于本章所述特定专用车情形。其基础车并不符合R155。表4-1对使用不符合要求基础车的完成车，已经在2027年6月1日设置注册节点；不能仅引用“R155完成车到2028年6月1日”就认定该车仍可注册。[1，附件XII表3]

如果基础车已符合R155，则还需证明后续阶段符合其当时适用条件，并没有破坏基础车符合性。这时才有必要进一步分析完成车自身的2028年节点。相同判断方法用于R156：2029年完成车日期不取消2027年关于不符合要求基础车的条件。[1，附件XII表4]

上述推演仅使用已明确的分类和日期，不预设任何库存豁免或主管机关特批。改变车辆的法律分类、批准路径或取得有效的个案安排，都可能改变处理结果，但应分别提供依据，不能从该例自行推导。

4.12.3　挂车与专用车的适用性说明

对GB的O类车辆，应分别记录“R155在UN层面是否具备适用对象”和“GB是否将其列为强制项目”。R156则结合实际软件更新能力及相应批准类别判断。没有无线通信并不当然排除诊断接口、可更新制动电子单元等相关系统。[1；5，第1段；6，第1.1段]

对旅居车、救护车、装甲车、轮椅无障碍车辆、移动式起重机和特殊载荷运输车辆，必须将专用车定义、附件II对应表格、制造阶段和附件XII时间安排共同使用。不得只凭2029年的日期或某一类车辆的例外，得出整个专用车项目不需要CSMS、SUMS或车型证据的结论。[1，第2(3)(b)、2(5)条]

4.13　完整案例一：修复通信终端漏洞

4.13.1　已知条件与变化边界

以下为假设案例，不涉及真实企业、实际漏洞编号或批准结果。某M1纯电车型已具有适用的GB整车批准、R155／R156批准及有效体系证书。TCU硬件为C2，应用软件拟从5.2.0更新到5.2.1，目的是修复诊断消息处理中的输入校验缺陷。制造商初步声明不修改诊断服务权限、网关路由、更新信任根、车辆控制算法或用户可用功能。

这些“不修改”均是必须由差异分析和试验支持的前提，不能当作已经验证的事实。现有车辆包含维修后更换过TCU的个体，部分车辆的当前版本尚未确认。

4.13.2　风险判断与证据补充

第一步，由网络安全团队将供应商问题说明映射到本车型实际启用的功能、接口和组件版本，确认缺陷是否可到达及其可能后果。即使漏洞最终只导致通信服务失效，也要分析服务失效是否影响安全相关通信、远程诊断或更新能力，而不能仅凭“TCU不是制动控制器”排除车辆影响。

第二步，形成更新差异和回归计划。证据至少应证明修复代码及依赖变化范围、异常消息被正确处理、正常诊断和必要通信仍可运行、资源占用和异常重启未导致新的不可接受后果，以及更新执行和恢复机制未被破坏。涉及eCall接口的，按接口实际依赖安排相应验证，并明确TCU与eCall之间的具体功能关系。

第三步，更新TARA、措施及测试索引。这次补丁改变了网络安全措施和相关证明材料，不能因驾驶功能未改变就跳过R155第8.1段。项目应向原R155批准机关提交变更及更新证据，并按其决定确定是否维持既有批准、补充评估或办理扩展。[5，第7.3、第8段]

4.13.3　批准和RXSWIN的条件性结论

在证据支持所有上述边界的情况下，可以形成“未识别出对制动等其他批准系统的参数或试验覆盖的改变”这一受限结论；该结论限于已评价的功能及证据范围。R156影响评估仍需记录更新内容、目标状态和批准动作；若R156自身技术性能或申报资料也受到影响，应按其第8.1段处理。[6，第7.1.1.8—7.1.1.10、第8段]

若相关机关确认不需要某一受管系统的扩展或新批准，且其批准相关软件映射未改变，该系统对应RXSWIN可按原始系列规则维持；但TCU软件版本、完整性数据、目标车辆及更新记录必须改变。若R155或其他项目实际产生扩展，或批准相关映射变化，则应重新判断相应RXSWIN处理。漏洞修复是否涉及RXSWIN调整，取决于相关软件映射及法规条件。[6，第7.1.2、第7.2.1.2段]

4.13.4　部署与关闭

目标清单只纳入已确认C2硬件及适用前置版本的车辆。维修更换或状态不明的车辆先回读确认，错误硬件或不兼容组合不进入自动执行。OTA执行前检查车辆及供电条件，向用户提供目的、时间、限制和失败处理信息；安装后确认5.2.1实际运行及必要功能状态，下载、安装及实际运行状态分别留存。

该行动可按风险和响应期限安排受控分批部署，并设置暂停条件，例如更新失败超出内部已批准容限、出现新的服务异常或发现目标识别错误。分批策略是工程安排，不应被用于无理由延迟紧急风险处理。关闭记录应包含机关处理结果、发布基线、验证证据、完成车辆、未完成车辆及替代处置。风险监测随后继续评估修复效果。

本例的关键判断是：漏洞修复通常可以保留大量既有的非网络安全证据，但仍可能触发R155变更通知；是否扩展由实际影响和机关处理决定，不能由更新名称决定。

4.14　完整案例二：提高再生制动能力的标定更新

4.14.1　已知条件

以下同样为假设案例。某M1纯电动车拟将整车控制器中的再生功率上限标定由60 kW提高至80 kW，并调整制动控制器与整车控制器的协调策略。车辆硬件不变，更新计划通过OTA交付已注册车辆。60 kW和80 kW仅为假设设计输入，不是法规限值，也不代表车辆在全部荷电状态和温度下都能达到该功率。

与案例一不同，此次目的就是改变车辆受控功能的工作特性。即使制造商声称“只改软件、不改硬件”，R156第7.1.1.8—7.1.1.10段的批准影响评估仍明确相关。功率比由80÷60得到约1.33，不能据此推导减速度、制动距离或回收能量同样增加约33%；这些结果还取决于车速、质量、轮胎附着和电池接受能力。

4.14.2　逐项追踪受影响的批准证据

首先，应比较原批准资料中的制动系统说明、再生制动分类与协调策略、相关控制参数、代表配置和试验覆盖，重点判断现有制动证据是否包含新的控制状态。其次，应将电池高荷电状态、低温、通信故障和相关降级工况纳入变化分析，明确再生制动力减少或退出时摩擦制动的补偿和驾驶员感知是否受到影响。

还需分析由控制策略变化引出的相邻系统影响，例如制动灯控制的输入及阈值逻辑是否改变，原能耗或其他申报数据的覆盖是否受影响，以及更新后软件故障是否改变安全反应。这里列出的是必须评估的技术接口，不预先宣告每项都必须重做全套试验；具体适用条款、系列、限值和验证项目应接入第三章相应技术专题及该车型已有批准文件。

表4-9　假设再生制动更新的影响评估样例

表4-9是根据R156第7.1.1—7.1.2段组织的假设评估，不是某一机关已经认可的改型方案。[6]

4.14.3　从技术评估到合法发布

制造商应先将新控制策略、软件及标定差异、系统依赖和拟议验证计划提交相应技术服务机构及批准机关，判断是否可以在原型式范围内扩展，或是否已跨越型式定义而需新批准。R156本身不代替制动法规的批准决定；相关技术报告的范围和新软件配置须与最终批准一致。

只有在所需资料、试验和批准处理完成，并确认已注册车辆实施该变化的适用条件后，才能进行相应市场部署。发现更新会使车辆不再符合现行批准状态时，不能采用“先推送，后补证”。申请已经受理、内部开发试验合格或供应商表示软件可用，都不是替代批准的理由。[6，第7.1.1.8—7.1.1.10、第7.1.2.5及第8段]

部署前应确认每辆车的制动和VCU硬件、BMS及电池版本、前置软件及维修变更。将所有同名车型按VIN范围整体推送，会忽略同一车型内的硬件和系统差异。执行时应使车辆处于经验证的安全状态；更新后确认成组软件一致、必要故障检查和功能确认完成，再解除相应限制。

本例与案例一的批准处理差异，源于具体软件变化及其技术影响。区别在于：案例一的主要变化集中在网络安全措施和证据，其他批准可在证明无影响后继续使用；案例二主动改变受管控制特性，更容易触发现有资料、试验和批准范围的调整。两个案例都需要SUMS记录、正确的目标车辆、经验证的执行机制和可追溯的最终状态。

4.15　2026—2030年的项目控制重点

对于GB项目，近期首先要处理已到达的2026年新型式要求以及2027年完整车和基础车相关注册节点；多阶段项目再区分2028年的R155完成车节点与2029年的R156及专用车节点。计划应按批准、制造、上装、物流和注册事件倒排，分别明确各项要求的适用事件与完成条件。[1]

对于双市场平台，软件发布计划应与GB和NI分别维护的法律基线、批准版本和单车状态绑定。对R156国际修订，应记录最终文本、过渡和接受条件；不能因为较新系列已经国际生效，就宣布全部既有GB车型应在同一天切换，也不能忽略新系列对未来申请的影响。[4；7]

形成可持续运行的能力，需要将三件事连起来：第一，体系能够发现并处理实际风险；第二，车型证据能证明具体设计和更新符合要求；第三，生产及在用车辆的真实状态与这些证据一致。缺少其中任何一环，证书、试验报告和云端平台都只能证明局部事实，不能共同构成完整的市场合规结论。