几点意见|强国标《智能网联汽车 自动驾驶系统安全要求》

一图读懂《智能网联汽车 自动驾驶系统安全要求》强制性国家标准（征求意见稿）

这个标准可以说是未来L3/L4级自动驾驶车辆必须遵守的“安全底线”，为L3/L4级自动驾驶的“准生证”设定了硬门槛。它主要围绕“技术安全”和“管理安全”两大核心，确保车辆在无人接管或机器自主驾驶时，依然能像老司机一样稳当。

既然现在工信部在征求意见，作为车路云一体化的建设者，积极响应号召，经过仔细研究，准备提出如下几条意见，供参考。

意见一、补充“车路云协同”作为新型ODC要素与安全概念组成部分

考虑思路：

当前标准对“设计运行条件”（ODC）的定义（第3.10、3.11条）主要聚焦于车辆自身的感知能力（道路、交通、天气等）。在“车路云一体化”背景下，路侧智能设施（RSU），其他车辆提供的超视距感知、信号灯相位、道路危险预警等信息，以及云端下发的高精地图动态图层、交通调度指令、群体协同策略，将成为ADS安全、高效运行的关键依赖和新型ODC。

具体建议：

在 第3章“术语和定义” 中，考虑增加或修订“设计运行条件”（ODC）的定义，明确将 “可用的车路协同通信服务（V2X）与云端协同服务” 列为一项可选但重要的ODC要素。并相应定义其状态（如：可用、降级、不可用）。

在 第5.1.1条（一般要求） 或新增条款中，要求ADS应能识别并评估车路云协同服务的状态，并据此调整其行为能力策略（例如，当失去路侧超视距信息时，应主动降速或提高本车感知的警惕性）。

在 附录D（安全档案）的D.2.4（安全措施说明） 部分，要求车辆制造商说明，当ADS功能依赖或部分依赖车路云协同信息时，如何识别通信失效、信息冲突或信息延迟等风险，并制定了何种安全策略（如：切换至纯车载感知模式、触发降级或介入请求）。

意见二、明确云控平台在“部署后安全管理”与“安全档案”动态更新中的角色

考虑思路：

标准第6.1.8条和D.2.4.3.17条提到了“部署后安全管理”和运行阶段监测，但主要视角是车辆制造商。在车路云体系中，云控平台具备汇聚多车、多路数据的能力，能更早、更广地发现系统性风险（例如，某路段特定天气下多车出现相似感知误判）。

具体建议：

在 第6.1.8条“部署后安全管理” 中，鼓励或建议车辆制造商建立与国家级/区域级云控基础平台或合规第三方平台的数据交互机制，用于接收群体性安全预警和场景化安全补丁（如针对长尾风险的决策规则更新）。

在 附录D的D.2.7条（安全评估发布报告总结） 中，建议增加说明：车辆制造商如何利用云控平台反馈的真实世界运行数据（尤其是未知风险场景数据），对安全档案中的场景库、风险评估进行持续验证和动态更新。这能使安全档案从“一次性的准生证”变为“伴随车辆全生命周期的健康档案”。

意见三、为“协同式MRM（最小风险策略）”预留标准接口

考虑思路：

当前标准第5.1.6条规定的MRM是单车行为（如靠边停车）。在未来高密度自动驾驶交通流中，单车紧急停车可能引发次生风险。车路云系统可以实现协同式MRM，例如，由云控平台或路侧设施为故障车辆规划一条对交通影响最小的停车路径，并协调周围车辆进行避让。

具体建议：

在 第5.1.6条“最小风险策略” 中，增加一项说明性条款：“鼓励探索在具备可靠车路云协同通信条件下，执行与道路基础设施及其他车辆协同的最小风险策略，以进一步降低对整体交通流的安全风险。”

在技术层面，可在标准后续修订或相关配套标准中，考虑定义协同MRM的请求、响应、指令消息集的标准化数据接口，为未来产业落地预留空间。此建议可在“征求意见说明”中作为前瞻性研究方向提出。

意见四、将“网络安全”与“数据安全”深度融入SMS和交互要求

考虑思路：

标准多处提及“网络安全”，但车路云一体化将车辆从信息孤岛变为网络节点，面临 “云-管-端” 全链条安全威胁。V2X通信可能被干扰、伪造，云端指令可能被篡改，这直接威胁ADS安全。

具体建议：

在 第6.1.3条“风险管理” 中，强调在安全保障体系（SMS）的风险识别环节，必须系统性地分析 车路云通信链路被攻击、云端服务被入侵 可能引发的ADS安全风险。

在 第5.2章“人机交互” 和 第5.3章“用户告知” 中，考虑增加要求：当ADS检测到车路云通信遭受严重网络攻击或无法验证信息真实性时，应向用户明确提示 “协同功能受限” ，并执行预定义的安全策略（如忽略不可信的外部指令，回归保守驾驶模式），并将此事件记入DSSAD。

总体来说，主要思路是将现行以“单车智能”为核心的安全标准，向“单车智能+网联赋能”协同安全的范式进行延伸和补充。 并没有否定单车安全的基础性地位，而是提出了在系统更复杂、能力更强的未来场景下，如何通过标准引导，让车、路、云各司其职，共同构筑更高阶、更鲁棒的安全防线。