自动驾驶达到什么技术标准才能称为L3级？

[首发于智驾最前沿微信公众号]在谈及自动驾驶技术时，常会陷入两个极端，一方面是大家对“完全自动驾驶”的美好愿景，另一方面是自动驾驶技术飞速发展过程中对于“安全隐患”的担忧。L3级自动驾驶系统（ADS）恰好处在这两者的张力中——它需要在特定条件下代替人类完成全部动态驾驶任务，同时又必须留出人与机器之间明确的责任与边界。为了规范自动驾驶系统技术要求、保障交通安全与合规性、推动自动驾驶行业健康发展，由中华人民共和国工业和信息化部主管，国家市场监督管理总局、国家标准化管理委员会发布的《智能网联汽车 自动驾驶系统通用技术要求》（GB/T 44721-2024）应运而生（以下简称：标准），并于2024年9月29日正式实施。那标准到底规定了啥？怎样才算是达到L3级自动驾驶标准？

标准的核心目标，并不是空讲技术方向，而是把自动驾驶发展所涉及的“责任边界”与“能力边界”写成一套可验证、可执行的工程规则，让产品在能做的事上可靠做、在做不到的时候可控退出。整个标准从总体要求到感知、决策、人员监测、接管逻辑、提示与验证方法，都围绕“把风险保持在合理可接受的水平”来设计。

先从“设计运行条件”（ODC/ODD的表述相关）谈起。标准反复强调，ADS必须有明确的设计运行条件，并且只能在这些条件下被激活。ODC是把系统能力与外界复杂性做映射的契约。它要把道路类型、车速区间、车道标识清晰度、天气光照、GNSS可用性或数字化路侧信息等都写清楚。把这些条件声明清楚有两个直接效果，第一，对用户而言，系统的能做与不能做一目了然，减少误用；第二，对验证团队而言，试验范围有据可依，仿真、场地与道路试验的场景选择能更有针对性。换句话说，把“能在哪些场景工作”写清楚，是把“不确定性”转化为“可验证的假设”。标准对这一点的强调，正是把自动驾驶从概念化的能力宣称，变成工程化的声明与承诺。

标准部分截图

关于系统必须做到的“目标与事件探测与响应”（OEDR），标准把感知能力的要求具体化为识别道路、道路设施、其他交通参与者、障碍物、天气与光照等，并能测量位置和速度。从技术上探究，这要求一个融合多源传感器的感知链路，从底层的传感器标定与安装规范到上层的目标检测、轨迹预测与语义理解，都要形成闭环。标准不仅要求在正常状态下的探测能力，而且明确了“当感知性能衰退时要有合理的控制策略”。这条看似被动的规定，实际上要求团队在传感器选型、冗余设计与性能退化策略上做充分设计：要么通过冗余传感器保持功能能力，要么在检测到衰退时及时限制系统激活或执行最小风险策略（MRM）。把感知退化放进规范，实质上是要求从“我能看到”到“我知道我在什么条件下能看见”这条链路都要被工程化。

标准部分截图

说到最小风险策略，这是标准的另一个核心。它不是简单的“车停下来”，而是一个有先有后的控制流程，当系统检测到ODC即将失效、驾驶员没有在规定时间内接管，或出现严重失效时，ADS要能判断并执行可使风险降至可接受水平的控制动作。标准明确了两个关键时间相关的设计点，一是介入请求必须留出足够时间让驾驶员接管；二是在驾驶员未响应的情况下，介入请求从发出到升级并开始执行MRM的时间应不少于10秒。这10秒并非随意给出的数字，而是工程折衷的结果，最终目标是既要给人类足够时间理解并接手，也要保证在驾驶员没有接手时系统有足够的时间完成安全降速与靠边停车等动作。这个要求对HMI设计、驾驶员监测和车辆动力学控制提出了明确约束，提示必须快速、明确且可被感知，车辆控制必须能在提示升级到MRM前保持平稳与安全。

标准部分截图

与最小风险策略配套的，是对“发出介入请求”和“接管能力判定”的明确规范。对于需要传统驾驶员接管的ADS，标准要求系统具备驾驶员在位监测和驾驶员执行动态驾驶任务能力的监测，并且至少用两种有效指标来判定驾驶员是否具备接管能力，例如眼部状态、头部运动或特定的人机交互动作。标准甚至给出了在位监测的直接触发条件，驾驶员不在驾驶位超过1秒或未系安全带时，需要按规定发出介入请求或接管能力不足提示。这意味着车企不能仅靠“方向盘转动”的单一信号来判定人是否在位，而要设计融合摄像头、力矩传感器、座椅压力传感器等多模态判据，并设定判定周期与阈值，以确保在需要接管时真正有真人可以接手。

标准部分截图

在人机交互（HMI）方面，标准把“提示的清晰度与层级”写得非常具体。ADS的每一种状态——未激活、就绪、激活、介入请求、介入请求升级、MRM、失效、退出等——都应以直观且可区分的方式提示用户，且介入请求至少要在光学提示基础上附加声学或触觉提示，升级后还要增加持续或间歇性触觉提示。这样的规定源于对人感知与响应能力的实际考量，视觉提示在驾驶员分心或光照条件差时可能失效，声学提示在噪声环境中也可能被淹没，触觉（方向盘振动、座椅振动）则作为可靠的最后手段。这一要求的挑战在于，提示的语义需要与驾驶员心理模型一致，不同提示不能互相混淆，也不能过度打扰以至于造成焦虑或惊吓。标准把提示形式列入强约束，是为了强制厂商把HMI的研究从“好看”变为“有效且可验证”。

标准部分截图

标准对“激活与退出”的约束也反映了对误用风险的关注。要求ADS必须有专用的激活与退出操纵方式，并防止可合理预见的用户误用；且在需要传统驾驶员接管的系统中，只有在满足一系列条件（例如驾驶员在位并系好安全带、驾驶员具备DDT执行能力、没有影响ADS的失效、DSSAD可记录、车辆未在执行影响ADS的软件升级等）时ADS才能被激活。这样的规定看似繁琐，但其防御目标明确：在系统被错误激活后发生事故会引发法律与伦理风险，而把激活条件做成“多门槛合格”是降低这种风险的工程手段。同时，退出逻辑同样被严格限定，系统退出不得导致应急辅助功能或其他辅助功能的异常开关，退出也不应在非必要情形下触发，除非用户明确操作或系统执行MRM。换言之，标准在人的行为与系统能力之间建立了严谨的“握手协议”，保证离开自动驾驶状态的过程受到可控管理。

对“干预”规则的细化，也体现标准的现实主义。驾驶员干预分为横向（转向）与纵向（制动与加速）两类，标准明确当驾驶员的输入超过防止误用所设的合理阈值时，应执行人的输入；同时系统还要能检测驾驶员是否专注于DDT，某些阈值与驾驶员专注情况相关。这就要求转向/制动输入由高频采样的力矩/踏板传感器、方向盘角度传感器和驾驶员状态监测共同决策，确保当人做出有力且明确的干预时，机器让位，从而避免人机“拉锯”导致的控制冲突。并且，标准允许在极端情况下基于厂商声明对驾驶员干预进行暂缓或抑制，但要求明确说明适用场景和合理性，这为那些在极低概率但高危后果的情形里采取非直觉控制策略提供了合规路径，同时也要求厂商承担透明性责任。

标准部分截图

技术体系与文件化管理同样被强调。标准要求车辆制造商提供完整的系统描述、组件清单、布局与原理图、单元功能说明和安装规范，尤其对感知部件的安装细节作出说明，位置、外表材料、尺寸形状、光洁度以及可能影响ADS性能的安装规范都要记录在案。这些看似“纸上工作”的条款，实际上直接关系到量产一致性与后市场维护。感知性能不仅取决于算法，更取决于硬件安装工艺与车身电磁兼容、线束走向、传感器遮挡策略等。把这些要求放进标准，是为了解决在研发阶段很容易控制，但在规模化生产时容易变差的“从试验车到量产车”的性能迁移问题。

标准部分截图

安全管理与验证链路是标准另一组重量级章节。标准要求制造商建立覆盖开发、生产、运行、服务到报废的安全管理体系，进行功能安全（ISO26262风格）与预期功能安全（SOTIF风格）层面的危害与风险评估，并在验证与确认阶段采用“多支柱”方法——仿真、场地试验、道路试验与审核评估共同形成证明链。这主要是因为在某些极端场景在道路试验中不可穷尽，仿真能扩展样本空间；场地试验能在受控条件下复现危险场景；道路试验则验证系统与真实交通主体的互动。把这些方法论上升为标准，是为了规范验证策略，避免厂商只靠“路测里程”作证，而忽视了系统在边界场景或罕见组合下的表现。除此之外，标准还要求运行阶段的监控机制，比如自动驾驶数据记录系统（DSSAD）与远程安全监控，以便把线上的安全事件回传并形成闭环改进。这就把产品的安全保障从单次出厂的静态合格，扩展为“在场运行中持续可监控与可改进”的动态合格。

标准部分截图

把标准落到工程实践上，会遇到若干现实问题和设计权衡。首先是感知冗余与成本的权衡，满足OEDR的探测范围和退化策略，通常需要多传感器融合与冗余设计；这既增加硬件成本，也提出了传感器间时间同步、坐标对齐与故障隔离的工程难题。其次是驾驶员监测的隐私与可靠性问题，基于摄像头的眼动/面部监测效果好，但涉及隐私与复杂光照适应；基于方向盘力矩与手势识别可能更隐私友好，但对判定“注意力”可能不够敏感。再有是HMI的语义一致性，提示设计要兼顾不同用户对提示语义的认知模型，避免因词句、颜色或振动强度不同而引起误读。标准并没有直接告诉厂商该如何在每一处做选择，而是把边界和验证要求明确下来，真正的工程工作就是在这些边界下做折衷并形成可证明的验证证据。

这部标准的发布其实具有双重意义。一方面，它为国内企业提供了与国际接轨的技术框架，尤其是在验证方法与安全管理方面与国际“多支柱”共识保持一致，从而降低了合规不确定性。另一方面，标准通过把文件化、试验与运行监控变为必须条件，强化了厂商对“持续责任”的认识，自动驾驶不是交付软件就完事的单次事件，而是需要在全生命周期里对设计假设、场景覆盖与在线表现负责的长期工程实践。对于厂家而言，遵循标准意味着不仅要做出能跑的算法和能稳的控制器，更要能产出可追溯的文档、可再现的验证结果以及面向现场数据的监控改进机制。

总之，标准把L3及以上自动驾驶系统的若干关键点制度化，明确设计运行条件、细化感知与OEDR要求、规定接管与MRM的时间与提示机制、约束激活/退出与干预逻辑，并把功能安全与SOTIF式的预期功能安全贯穿开发到运行的全过程。对工程实践而言，这些规定不是“要你做文书”，而是要把那些本应就做的工程活动——场景定义、冗余设计、人机交互试验、故障注入验证、运行监控与数据闭环——都放在可验证与有证据的框架下执行。对于目标是把自动驾驶推向规模化部署的团队，这个标准给出的不是一张简单的合格单，而是一整套能支撑产品安全可信赖落地的方法论。