美国自动驾驶法案要求的“安全案例”

东海旭日——汽车观点 2026-03-10

美国通过新自动驾驶法案并要求企业提交技术安全证明，这是行业内的一个重大进展。

美国通过新自动驾驶法案并要求企业提交技术安全证明，这是行业内的一个重大进展。虽然最终法案的全貌还需等待NHTSA的具体规则，但从已提出的《2026年 SELF DRIVE Act》和相关的行业讨论中，其中要求车企必须提交完整技术安全证明，包括：

运行设计范围（ODD）、风险评估体系、碰撞规避逻辑、网络安全机制、故障最小风险策略。

这五项要求共同构成了一个名为“安全案例（Safety Case）”的强制性技术档案。它的核心逻辑是要求制造商像在法庭上辩护一样，用一整套“主张-论据-证据”的链条，向监管机构证明其自动驾驶系统“不会带来不合理的风险”。下面来具体看看这五项具体要求。

1. 运行设计范围（ODD）

这是自动驾驶系统功能的“说明书”和“边界线”。法案要求制造商必须提供一份毫无保留的完整描述，明确界定其自动驾驶系统在什么条件下才能安全工作。

*具体内容：这一定义非常严谨，必须包含所有限制条件，例如：

*地理限制：是只能在高速公路（如特定的高速路段）运行，还是仅限于地理围栏内的城市道路？

*环境限制：只能在晴天工作，还是能应对小雨、大雾或夜间场景？

*道路特性：是否需要清晰的车道线？能否应对复杂的路口或无保护左转？

*关键要求：系统必须能准确识别自己是否正在驶出这个预设的“舒适区”。这就像一个员工必须清楚自己职权的边界，一旦超出范围，就必须上报（触发后面的“最小风险策略”）。

2. 风险评估体系

这项要求相当于要求制造商交出内部的风险“账簿”。它要求企业披露在设计和测试过程中，是如何识别、分析和评估各种潜在危险的。

*具体内容：

*方法论：你必须说明采用了哪种工程方法（如HARA——危害分析与风险评估）来系统地找出所有可能的危险场景。

*接受标准：对于那些无法完全消除的风险，你凭什么认为它是“可接受的”？例如，系统可能无法100%识别远处路面上的一个小坑洼，但制造商需要论证，根据其算法，这种情况发生的概率极低，或者即使发生，后果也极其轻微，因此整体风险是“合理”的。

*核心意义：这改变了监管逻辑。监管机构不再试图去“看懂”每一行代码，而是审查你评估风险的逻辑和方法是否科学、完备。

3. 碰撞规避逻辑

这是关于自动驾驶系统在路上的“实时驾驶技术”和“临场反应”。法案要求制造商详细解释，系统是如何像一位经验丰富的司机一样，预见危险并主动避开。

*具体内容：

*常规驾驶能力：系统如何在其ODD内完美执行全部的“动态驾驶任务”（DDT），包括加减速、转向、变道等。

*主动规避能力：更重要的是，系统如何“预期和响应任何潜在的碰撞”。这意味着需要详细说明：

*它是如何检测到“鬼探头”的行人或突然切入的车辆的？

*它的决策算法是怎样的？是优先刹车还是急转向？在面临无法避免的碰撞时，其最小化伤害的逻辑是什么？

*特殊场景处理：针对“弱势道路使用者”（如行人、自行车骑手），系统是否有专门的、更谨慎的应对模型。

4. 网络安全机制

在智能网联汽车时代，这是防止车辆被远程“绑架”的“免疫系统”。法案明确要求制造商必须具备完备的网络安全计划。

*具体内容：制造商必须详细阐述其多层安全防御体系。从已有的行业实践来看，这通常包括：

*隔离：将核心的驾驶控制系统与娱乐系统、远程通信系统进行物理或逻辑隔离，确保即使车载娱乐系统被攻破，也无法触及刹车和方向盘。

*认证与加密：所有关键的车辆指令和软件更新都必须经过严格的身份认证和加密传输，防止被篡改或伪造。

*漏洞管理：是否有像特斯拉那样的“漏洞赏金计划”，主动邀请安全研究者来发现并报告漏洞？对于已发现的漏洞，有多快的响应和修复机制？

5. 故障最小风险策略（MRC）

这是自动驾驶系统的“最后一道安全防线”或“降落伞”。它规定了当系统遇到无法处理的“意外”时，该如何安全地“退场”。

*具体内容：

*触发条件：什么情况会触发MRC？主要包括两类：一是系统自身发生关键故障（如核心传感器失灵）；二是车辆意外地驶出了其被设计的ODD范围。

*执行动作：一旦触发，系统必须执行“DDT回退”，也就是将车辆带入一个“最小风险条件”。这通常指让车辆安全地靠边停车，打开双闪，进入一个稳定的静止状态。

*人机交互：在达到最小风险条件的过程中或之后，系统如何警示周围的其他车辆和路人？例如，是否会通过特定的灯光或声音信号告知周围“我出故障了”？

总的来说，这五项要求构建了一个从能力边界（ODD）、风险认知（风险评估）、主动防御（碰撞规避）、到被动抗干扰（网络安全）和最终安全保障（MRC）的完整安全闭环。

这种以“安全案例”为核心的监管模式，标志着监管思路的重大转变：从过去试图审查“代码怎么写”，转向了要求企业证明“结果是安全的”。这对于采用“端到端大模型”的特斯拉FSD等先进技术来说，无疑是重大的政策松绑，因为监管机构不再需要看懂那个复杂的“黑盒”，而只需要审查其提供的安全证据链。

为了方便理解，这五项要求的关键点整理如下：

安全证明要求	核心含义	法案中的关键要求
运行设计范围 (ODD)	系统的“使用说明书”与“能力边界”	完整描述系统工作的地理、环境、时间等限制，并能自我识别是否超出此边界。
风险评估体系	企业内部的“风险账簿”	披露识别、分析、评估风险的方法论（如HARA），并说明接受残余风险的标准。
碰撞规避逻辑	系统的“实时驾驶技术与应变能力”	详细解释系统如何执行驾驶任务，以及如何预期、响应和避免各类潜在碰撞。
网络安全机制	防止车辆被攻击的“免疫系统”	阐明其多层安全架构，包括隔离、加密、认证及漏洞管理等具体防护措施。
故障最小风险策略 (MRC)	系统失效时的“安全降落伞”	规定在系统故障或超出ODD时，如何执行安全停车等操作，将车辆带入“最小风险条件”。