说清楚你的生意，拿走一份能派工的义务清单

由车辆制造商或其正式授权代表向缔约方指定的审批机关申请 CSMS 评估；评估通过并提交附件 1 附录 1 格式的签署声明后，按附件 4 格式颁发 CSMS 合规证书。证书自颁发之日起最长有效 3 年，除非被撤销；制造商须在有效期届满前留出足够时间申请换发或延期，并须就任何影响证书相关性的变更主动通知审批机关或技术服务机构，由其决定是否需要新的检查。

需留存证据：CSMS 合规证书（附件 4 格式）及其有效期台账；附件 1 附录 1 格式的制造商签署声明；CSMS 评估报告与不符合项关闭记录；证书换发/延期申请的提前量管理记录；影响证书相关性的变更通知与审批机关答复

制造商须识别车型的关键要素，对该车型开展穷尽风险评估并适当处置/管理已识别风险。评估须考虑车型各个要素及其相互作用，并须进一步考虑与任何外部系统的交互；评估风险时须考虑附件 5 A 部分列明的全部威胁以及其他相关风险。未做穷尽风险评估、或未考虑附件 5 A 部分全部威胁的，审批机关应拒绝授予批准。

需留存证据：车型关键要素清单与系统边界定义；TARA（威胁分析与风险评估）报告，含附件 5 A 部分威胁逐项对照表；外部系统交互（云平台、充电桩、手机 App、V2X）风险分析；风险处置决定与残余风险接受记录；风险评估保持最新的流程与复评记录

制造商须证明其 CSMS 具备监测、检测并响应车型网络攻击、网络威胁与漏洞的流程，并能评估既有网络安全措施在新威胁面前是否仍然有效；监测须是持续的，须把首次注册后的车辆纳入，并具备从车辆数据与车辆日志中分析和检测威胁、漏洞与攻击的能力，同时尊重车主或驾驶人的隐私权（特别是同意问题）。对需要响应的威胁与漏洞，须在合理时限内完成缓解。制造商还须具备提供相关数据以支持已遂或未遂网络攻击分析的流程。

需留存证据：车辆安全运营中心（VSOC）建设与值守流程文件；威胁情报来源清单与漏洞分级、响应时限（SLA）规定；车辆日志采集范围、最小化与同意机制说明；监测告警、处置工单与闭环记录样本；支持攻击分析的数据留存与提供流程

AI 事件与严重事故报告记录（事件台账 + 对外报告底稿）

制造商须针对风险评估识别出的风险保护车型，实施相称的缓解措施，其中须包含附件 5 B、C 部分中与所识别风险相关的全部缓解措施；若某项缓解措施对所识别风险不相关或不充分，制造商须确保实施另一项适当的缓解措施。对 2024 年 7 月 1 日之前的型式批准，制造商在附件 5 B/C 措施技术上不可行时可实施替代措施，但须向审批机关提交技术可行性评估。

需留存证据：附件 5 B/C 缓解措施与车型实现的对照矩阵；不相关/不充分判定及替代措施说明；缓解措施验证与渗透测试报告；（如适用）技术不可行性评估及提交审批机关的记录

制造商须证明其 CSMS 如何管理与签约供应商、服务提供商或制造商内部下属组织之间可能存在的依赖，以满足第 7.2.2.2 段的各项要求（包括风险识别、风险管理验证、网络安全测试、风险评估保持最新、监测检测响应等）。实践中体现为把网络安全要求写入采购规范与合同、对供应商开展审核、并约定漏洞通报与配合调查义务。

需留存证据：供应商网络安全要求清单（Cybersecurity Interface Agreement 或等效文件）；供应商审核计划、审核报告与不符合项关闭记录；漏洞与事件通报条款、响应时限与演练记录；集团内部组织职责划分与接口定义文件

供应商与分包商 ESG 与安全尽调问卷（本企业作为采购方使用）

经审批机关或其技术服务机构评估合格并收到附件 1 附录 1 格式的签署声明后，按附件 4 颁发 SUMS 合规证书，自颁发之日起最长有效 3 年，除非被撤销。有效期届满时，审批机关在评估通过后颁发新证书或延长 3 年；若期间发生变更且已提请审批机关注意并经重新评估通过，则颁发新证书。与本法规相关的信息须在制造商处形成文件并安全保存，应审批机关或技术服务机构要求可提供。

需留存证据：SUMS 合规证书（附件 4 格式）与有效期台账；附件 1 附录 1 格式的制造商签署声明；SUMS 评估报告与不符合项关闭记录；与本法规相关文件的安全保存与调取流程说明

RXSWIN 是制造商定义的专用标识符，代表与型式批准相关的电子控制系统软件信息。每个 RXSWIN 须可唯一识别；制造商修改型式批准相关软件并导致批准扩展或新批准时，须更新 RXSWIN。每个 RXSWIN 须能通过电子通信接口（至少经 OBD 标准接口）以标准化方式便捷读取；若 RXSWIN 不保存在车上，制造商须向审批机关申报车辆或单个 ECU 的软件版本及其与相关型式批准的对应关系，并在每次版本更新时更新该申报，同时保证软件版本可经电子通信接口标准化读取。制造商须保护车上的 RXSWIN 与软件版本不被未经授权修改，并在型式批准时以保密方式提供所采取的保护手段。

需留存证据：RXSWIN 定义文件与车型—RXSWIN—型式批准对应表；OBD/电子接口读取 RXSWIN 的验证记录；RXSWIN 与软件版本防篡改设计说明（保密件）及其测试报告；（RXSWIN 不在车上时）向审批机关申报软件版本的记录与更新日志

制造商须有流程评估、识别并记录某项软件升级是否影响车辆安全与持续运行所需的其他系统，或相对于车辆注册时是否新增/改变了车辆功能。对每个 RXSWIN，须保有可审计的登记册，描述升级前后与该 RXSWIN 相关的全部软件，包括各项相关软件的版本与完整性校验数据。这两项构成 OTA 升级是否需要型式批准扩展或新批准的判定底稿。

需留存证据：升级影响评估模板与逐次升级的评估记录；每个 RXSWIN 的可审计软件登记册（含升级前后版本与完整性校验数据）；型式批准扩展/新批准的判定结论与提交记录；登记册的访问控制与留存策略

对空中下载升级，制造商须确保升级失败或中断时车辆能恢复到先前版本，或能进入安全状态。制造商须有流程使车辆用户能被告知升级相关信息，并在需要时提供有助于用户安全执行升级的说明。这两项直接决定出海车队的 OTA 发布策略（升级窗口、行车中禁止升级、用户确认与提示文案）。

需留存证据：升级失败回滚/安全状态设计说明与断电、断网中断测试报告；用户告知流程与各语言提示文案定稿；安全执行说明（升级前置条件、时长、可否用车）；灰度发布与回滚预案演练记录

按本法规申请 M1 类车辆的 ALKS 型式批准，明确车型在 ALKS 方面的界定要素（显著影响 ALKS 性能的车辆特性、ALKS 的系统特性与设计）。系统激活后须替代驾驶人执行驾驶任务、管理包括故障在内的各种情形，不得危及车内乘员或其他道路使用者的安全，且驾驶人可随时超控。须实现向驾驶人安全移交驾驶任务的流程，并在驾驶人未适当响应时执行最小风险操作使车辆停下。

需留存证据：车型 ALKS 界定文件（影响性能的车辆特性与系统设计说明）；运行条件（道路类型、速度、天气、交通场景）边界定义与超出边界的退出策略；失效安全响应设计与故障注入试验报告；接管请求（transition demand）与最小风险操作 MRM 的设计与测试记录；人机界面设计说明（含接管时中止非驾驶活动显示的实现证据）

就“系统”所用的软件与硬件，制造商须以安全管理体系的形式向型式批准机关证明：组织内已建立、保持更新并实际遵循有效的流程、方法与工具，以在产品全生命周期（设计、开发、生产、运行、退役）管理安全与持续符合性；设计与开发流程须涵盖安全管理体系、需求管理、需求实现、测试、失效跟踪、补救与发布。制造商还须与供应商作出适当安排（如合同安排、明确接口、质量管理体系），确保供应商的安全管理体系符合相应要求。

需留存证据：安全管理体系手册与生命周期流程图（设计、开发、生产、运行、退役）；需求管理、实现、测试、失效跟踪与发布的过程记录与追溯矩阵；过程审核报告与不符合项关闭记录；与供应商的安全接口协议、质量管理体系证明与审核记录

每辆装备 ALKS 的车辆须配备 DSSAD，用于判定 ALKS 与人类驾驶人之间的交互；DSSAD 须记录法规定义的“事件（occurrences）”，即需要在数据存储系统中留存的动作或事件实例。制造商须在按附件 4 进行安全方案检查时，向技术服务机构证明第 8 段各项规定已得到满足；同时 DSSAD 处于可运行状态是系统正常激活条件之一。

需留存证据：DSSAD 设计规格与“事件”定义映射表；DSSAD 记录完整性、防篡改与读取方式的测试报告；DSSAD 运行状态作为系统激活条件的验证记录；DSSAD 数据保存期限、访问授权与向当局提供的流程

制造商须有流程监测由已激活的自动车道保持系统引起的安全相关事故、碰撞与事件，并有流程管理注册后出现的潜在安全相关缺口（现场监测闭环）并对车辆实施升级；须把关键事件（例如与其他道路使用者的碰撞、潜在安全相关缺口）报告给型式批准机关。这要求把海外车队的事故数据回传、分析与整改动作与 OTA 升级流程打通。

需留存证据：现场安全事件监测流程与分级标准（何为“关键事件”）；事故/事件台账与根因分析报告；向型式批准机关报告关键事件的报送记录与回执；安全缺口整改与 OTA 升级的闭环记录

AI 事件与严重事故报告记录（事件台账 + 对外报告底稿）

对现有机器人型号逐条比对 2011 版与 2025 版要求，列出需要重新设计、重新验证或仅需更新文档的条款，形成迁移计划与时间表；对已在海外销售的机型明确“继续按 2011 版声明”与“升级到 2025 版”的分界，并在客户技术规范与投标文件中统一表述所依据的版本与年份。

需留存证据：2011 版与 2025 版条款级差距分析表；迁移计划（责任人、里程碑、受影响型号清单）；重新验证试验计划与结果；对外技术规范/投标文件中标准版本表述的统一口径文件

机器人本体合规不等于应用合规：须按 ISO 10218-2 对具体应用与机器人单元（含末端执行器、工件、周边设备、围栏与安全装置、人员进入路径）做集成层风险评估，确定安全防护措施与人机协作模式，并把本体制造商在装配声明中列明的使用限制逐条落实或加以替代措施。

需留存证据：机器人单元集成风险评估报告（含布局图与人员进入分析）；安全功能清单及其性能等级（PL/SIL）论证；本体装配声明中使用限制的逐条落实记录；协作操作模式选择依据与速度/距离/力限值参数记录

ISO 10218-1 明确不适用于水下、执法、军用（国防）、空中与空间机器人，也不适用于医疗机器人、护理机器人、假肢与助残器具、服务机器人、消费品以及举升或运送人员的设备。企业在对外宣称“符合 ISO 10218”前须核对产品是否落在该范围内，避免对具身智能服务机器人、配送机器人、陪伴机器人做出不成立的符合性主张，并为这些品类另行确定适用标准与安全论证路径。

需留存证据：产品品类与标准适用范围的映射表；对外宣称符合性声明的审核记录（法务/合规会签）；范围外品类的替代标准与安全论证路径说明