上一篇文章我写了《自动驾驶系统安全要求》附录B 应用于高速公路和/或城市快速路的 3 级自动驾驶功能具体技术要求解读 这篇我将接着解读附录C。

一辆 L4 自动驾驶车辆在限定区域内运行，前方道路因施工临时改道。车辆既不能把驾驶任务交给一名并不存在的“后援驾驶人”，也不能把处置责任推给远程平台。它需要自己识别道路变化、规划通行方案；如果无法继续安全行驶，还要把车辆带到一个尽可能降低风险的静止状态。

这正是 L4 与 L3 在安全架构上的关键差异。

报批稿将 4 级自动驾驶功能定义为：有设计运行范围（ODD）限制，但不需要后援用户的自动驾驶功能。这里的“不需要后援用户”，不等于没有用户、没有运营人员，也不等于车辆可以在任何道路和天气下运行。它意味着，在功能规定的设计运行条件内，动态驾驶任务以及能力边界出现后的安全兜底，不能依赖某个人及时接管。

附录 C 是规范性附录，名称为“4 级自动驾驶功能具体技术要求”，结构十分清晰：C.1 规定动态驾驶任务（DDT）怎样执行，C.2 划定远程协助的能力边界，C.3 规定激活、退出、干预和状态提示。三个章节共同回答一个问题：没有后援用户时，系统如何形成完整而可验证的安全闭环。

图 1：根据报批稿附录 C 的条款关系整理。图示用于解释 L4 的安全闭环，不替代标准原文。

读懂附录 C，先避免两个常见误解

第一个误解，是把 L4 理解成“无条件无人驾驶”。实际上，L4 仍受 ODD 和设计运行条件（ODC）限制。特定道路类型、天气、道路设施、车辆状态、软件状态以及规划路径，都会影响功能能否激活和继续运行。系统不需要后援用户，不代表它没有边界，而是要求它在边界内独立驾驶，并在到达边界时自行安全收尾。

第二个误解，是把远程协助理解成远程驾驶。附录 C 明确要求，ADS 不应依赖远程协助执行动态驾驶任务；即使进入远程协助流程，ADS 仍应独立执行全部动态驾驶任务，并结合实时行驶环境安全响应远程提供的信息。远端可以提供策略性帮助，但不能成为一名通过通信链路持续操纵车辆的“云端驾驶人”。

第一章 C.1 DDT 执行：没有后援用户，系统怎样把驾驶任务做完整

附录 C.1 覆盖一般驾驶、换道、紧急避撞和最小风险策略。与 L3 一样，L4 功能激活后要持续执行全部动态驾驶任务；不同的是，当系统无法继续正常运行时，L4 不能把最终处置建立在驾驶人接管之上，而要自行完成风险收敛。

1.1 正常驾驶不只要稳定，还要应对道路的临时变化

附录 C 首先要求 ADS 使车辆保持在车道内，不能无目的跨越车道边线；横向和纵向运动应保持稳定，避免干扰其他道路使用者。这是自动驾驶行为可预期性的基础。

但 L4 的运行环境不会始终保持在高精地图或既定规划中的理想状态。道路施工、交通管制、临时锥桶和车道改移，都可能让实际道路与先验信息出现差异。C.1.1.2 因此专门要求 ADS 具备采取合理控制策略，应对道路因施工、交通管制等情况发生临时变更的能力。

这项要求并没有规定一套唯一的绕行算法，却明确了产品能力的审查方向：系统不能只在道路结构固定时正常工作，还应识别临时交通组织并作出安全响应。企业需要说明系统能够识别哪些临时变化、采用何种策略、何时判断无法继续，以及如何验证这些判断不会造成不合理风险。

对于碰撞风险，附录 C 列出了三类对象：

• 前车减速、邻车切入、逆向车辆以及突然出现的障碍物；
• 行人、自行车骑行者等弱势道路使用者；
• 无法识别类型的目标。

最后一类尤其值得关注。现实道路中，感知系统可能看见一个物体，却无法稳定判断它究竟是散落货物、异形车辆部件还是其他障碍物。附录 C 没有允许系统以“类别未知”为由忽略风险，而是要求其识别碰撞风险并执行合理控制策略。这意味着，目标分类的不确定性仍要进入风险决策，系统需要对“看见但认不清”的对象保持安全响应能力。

1.2 对载客车辆，安全还包括站立乘客的可承受性

如果车辆允许乘客站立，或允许不佩戴乘员约束系统，急加速、急转向和急制动会显著放大车内伤害风险。C.1.1.4 因此规定：除安全档案中描述的特殊情况外，ADS 发出的水平方向加速度和减速度指令均不应大于 2.4 m/s²，水平方向加速度和减速度变化率均不应大于 5.0 m/s³。

这里的水平方向加减速度，是横向和纵向的综合计算值，并非只约束制动。它会同时影响转弯、变道、起步和停车策略。对于自动驾驶公交、接驳车等可能允许站立乘客的产品，舒适性控制由此不再只是体验指标，也进入了明确的安全约束。

条款同时保留了特殊情形。例如，应对急迫碰撞风险时，车辆可能需要突破常规运动限制以避免更严重的后果。但这种例外需要在安全档案中描述，不能被泛化为日常驾驶策略。

1.3 换道和紧急避撞沿用严格的多车风险判断

附录 C 对换道没有重复列出全部参数，而是引用附录 B 中的若干要求。L4 换道同样要保证规划路径不与其他道路使用者发生碰撞，行为应可被其他道路使用者预期并安全响应，转向灯应合理开启和关闭。

进入换道执行阶段前，ADS 还要确认目标车道相关区域——至少包括潜在车辆存在区域——预计不会被其他车辆占用；进入执行阶段后，横向运动目标要保持连续，额外横向加速度目标不大于 1 m/s²。换句话说，L4 并不会因为“不需要驾驶人接管”而降低换道安全要求。

紧急避撞同样引用附录 B 的核心规则。系统既要对急迫碰撞风险及时控制，也要避免把眼前风险转移给相邻车道或其他道路使用者。若跨越车道线属于紧急避撞的一部分，其整体安全性不能低于通过制动避免该风险的安全性；跨线轨迹不能与其他道路使用者发生碰撞，并要通过转向灯向外界提示。

C.1.3 还增加了对控制连续性的要求：除非急迫碰撞风险已经消失，紧急避撞控制不应被终止。风险消失后，ADS 仍保持激活状态；若避撞使车辆静止，应开启危险警告信号，车辆重新起步后再关闭。这里没有设计一个“紧急动作结束就把控制权交给人”的出口，因为 L4 本身不依赖后援用户。

1.4 MRM 的目标，是把风险收敛到可维持的静止状态

当 ADS 无法继续正常执行驾驶任务时，最小风险策略（MRM）负责把车辆带到最小风险状态（MRC）。报批稿把 MRC 定义为尽可能降低碰撞风险的稳定、静止状态。因此，MRM 不是一次简单的减速指令，而是一套可能包含车道保持、换道、停车、外部提示和状态确认的连续过程。

除安全档案描述的特殊情况外，MRM 的减速度指令不应大于 4.0 m/s²。执行期间应开启并保持危险警告信号；如果 MRM 需要换道，进入换道执行阶段前要改用相应转向灯提示，完成换道后及时关闭转向灯并重新开启危险警告信号。

更重要的是，车辆到达 MRC 后不能因为时间经过、用户按键或通信恢复就自动离开。C.1.4.3 要求，在未确认导致 MRM 的原因已经消除前，ADS 不应使车辆脱离 MRC。确认方式可以包括 ADS 自检、车内用户查验或远程查验。

这条要求把“停车”与“恢复”分成两个独立的安全决策：首先要安全停下，然后要证明触发风险已经消除，车辆才可以重新进入运行状态。对于 L4 产品，恢复机制与停车机制同样需要被设计和验证。

第二章 C.2 远程协助：远端提供信息，驾驶责任仍在车端 ADS

远程协助是附录 C 最容易被误读的部分。它的价值在于帮助车辆理解异常情形、选择处置策略或完成脱困，而不是把动态驾驶任务从车端转移到远端。

2.1 三条边界，把远程协助与远程驾驶区分开

C.2.1 建立了三条核心边界。

第一，ADS 不应依赖远程协助执行动态驾驶任务。这意味着，网络连接和远端人员不应成为车辆维持基本驾驶能力的必要条件。

第二，远程协助过程中，ADS 仍应独立执行全部动态驾驶任务，且不能对车内用户和其他道路使用者造成不合理安全风险。即使远端建议绕过障碍、沿某条轨迹脱困，感知、风险判断和车辆运动控制仍由 ADS 完成。

第三，ADS 要基于当下行驶环境安全响应远程协助信息。远端信息不能被车端无条件执行。如果建议与实时交通环境冲突，车端系统仍要作出安全判断。

因此，远程协助更接近“提供策略信息”，而不是“实时接管方向盘和制动”。其安全责任链也由此保持连续：远端信息进入系统后，车端 ADS 仍是执行全部动态驾驶任务和实时环境响应的主体。

图 2：根据报批稿 C.2 整理。远程端提供协助信息，车端 ADS 结合实时环境独立执行全部动态驾驶任务。

2.2 远程协助不能随意触发，通信失败也要有车端退路

附录 C 要求，除安全档案中描述的情况外，ADS 不应触发远程协助。条款注释列举的典型场景包括车辆发生碰撞、车辆需要脱困，以及车辆或 ADS 发生失效。

这说明，远程协助应有清晰的触发条件、流程和权限边界，而不应成为系统遇到任何不确定情形时的默认依赖。制造商需要在安全档案中说明何时请求协助、传递什么信息、远端可以提供什么建议、车端如何判断，以及协助失败后如何处置。

通信链路本身也被纳入安全设计。ADS 要能够检测远程协助所需的通信状态，包括信号强度、网络时延和时延抖动等；车端还要具备与远程协助技术特性相适应的安全策略。例如，远程平台服务器发生故障时，车辆仍应有策略保障安全运行。

如果通信状态不能满足要求，导致远程协助触发失败，ADS 应执行合理控制策略以最小化风险，条款举例包括执行 MRM。这进一步说明：通信可用时，远程协助可以扩展异常处置能力；通信不可用时，车端仍必须能够自行安全收尾。

2.3 远程平台要获得足够信息，但“看见车辆”不等于“驾驶车辆”

为了使远端能够作出有效协助，ADS 应及时发送和接收远程协助信息，并至少具备上传四类信息的能力：

• 车辆状态，例如速度、车辆失效和碰撞信息；
• ADS 状态，例如运行状态和 ADS 失效信息；
• 车辆周围环境，例如感知目标和道路情况；
• 远程协助信息的接收结果。

这四类数据形成了一个基本闭环：远端需要知道车辆是什么状态、系统是什么状态、周围发生了什么，以及发出的协助信息是否已被车端收到。但条款并没有因此改变远程协助的性质。数据上传用于形成判断基础，信息回传用于提供策略支持，最终的实时驾驶仍由 ADS 根据现场环境独立完成。

对企业而言，这会把远程协助平台的设计重点从“远端能不能开车”，转向权限控制、信息完整性、时效性、通信质量监测、车端安全判断和失联处置。平台能力再强，也不能替代车辆自身的 DDT 和最小风险能力。

第三章 C.3 人机交互：能否在行驶中退出，决定两套不同的产品架构

L4 不需要后援用户，但并不意味着不需要人机交互。乘客要知道行程状态并能请求停车；坐在驾驶位的车内用户可能被允许干预；部分产品可以在行驶中安全移交至人工驾驶，另一些产品则不具备这一出口。附录 C.3 正是围绕这些不同产品形态划定边界。

3.1 激活前，不仅车辆和道路要合适，规划路径也必须在 ODD 内

除用户执行激活操作外，L4 功能还要同时满足多项条件：不存在影响 ADS 运行的失效；DSSAD 可用且存储区域未被锁定事件占满；天气和道路设施允许运行；ADS 完成自检；车辆没有执行影响 ADS 运行的软件升级；规划路径不超出 ODD 的道路类型范围；并满足安全档案描述的其他设计运行条件。

与只判断当前位置是否在服务区相比，“规划路径不超出 ODD 的道路类型范围”提出了更完整的要求。系统要在出发前评估从出发地到目的地的路径，不能只在驶近边界时才发现后续路段不属于其能力范围。

这也解释了为什么 L4 的“自动”通常与限定区域、限定路线或限定运营条件同时出现。ODD 不是营销标签，而是激活决策和安全验证的一部分。

附录 C 还要求 ADS 向乘客提供请求停车的方法，并向车内用户提供行程相关信息。对于没有传统驾驶员的车辆，这些基本交互承担着重要作用：乘客需要能够表达结束行程或停车的需求，也需要知道车辆当前处于什么状态、接下来将如何处置。

3.2 两类退出机制，不能混为同一种“L4 接管”

附录 C 将 L4 功能分为两类：允许在行驶中退出至人工驾驶的功能，以及不允许在行驶中退出至人工驾驶的功能。两者的责任结构明显不同。

对于允许行驶中退出至人工驾驶的功能，车辆运动时原则上也不能随意退出。只有三类情形被允许：将车辆控制权安全移交给车内用户；安全切换至 L3 自动驾驶功能；安全切换至自动泊车功能。紧急避撞正在执行时，退出还可能暂缓到急迫碰撞风险消失。

如果激活或退出操纵方式设置在驾驶区域之外，非驾驶位用户的操作不能绕过驾驶人确认。人工驾驶过程中，非驾驶位用户请求激活 L4，功能激活前应获得驾驶人确认；非驾驶位用户请求退出至人工驾驶时，则要获得坐在驾驶位的车内用户同意担任驾驶人的确认。核心原则是：控制权不能在接收者不知情、未同意或不具备条件时被交出。

对于不允许行驶中退出至人工驾驶的功能，只要车辆还在运动，除安全切换至 L4 自动泊车功能外，L4 功能就不应退出。若车辆设有用于人工驾驶或维修等模式的退出装置，该装置也只能在车辆静止时得到响应。

这类产品可能包括没有传统驾驶位或不以车内人工接管为运行方案的车辆。它的安全闭环不是“出现问题后找人接管”，而是“系统保持控制并执行 MRM，车辆静止后再处理”。

图 3：根据报批稿 C.3.2 和 C.3.3 整理。两类 L4 功能采用不同的行驶中退出边界，不能用同一套“接管”逻辑概括。

3.3 允许人工干预，不等于把车内用户变成 L3 后援用户

对于允许坐在驾驶位的车内用户干预的 L4 功能，附录 C 规定了转向、制动和加速输入的响应原则。

转向干预超过为防止误用而设置的合理阈值时，用户输入应被执行。阈值应包含特定的力或力矩、相应持续时间，并与用户注意力情况相关。若转向输入会导致急迫碰撞风险，ADS 可以按照安全档案描述的方式减弱或抑制其影响。

如果允许转向干预，ADS 还要检测坐在驾驶位的用户是否注意力集中。判断可以依据用户是否注视前方道路、后视镜，头部运动是否主要朝向驾驶任务相关区域，或安全档案中具有同等安全性的其他情况。

对于制动，用户输入产生的减速度大于 ADS 当前控制产生的减速度，或通过制动使车辆保持静止时，制动输入应被执行；加速干预即使被执行，也不能导致 ADS 违反本文件的其他要求。

这些条款允许特定产品保留人工干预能力，但它并没有把 L4 重新变成 L3。L4 的基本定义仍是不需要后援用户，系统不能把异常处置寄托在车内用户一定会响应上。人工输入是一种被产品设计允许的交互路径，不是 L4 安全闭环成立的前提。

3.4 状态提示要让用户知道“正在自动驾驶”，也知道“为何不能激活”

对于允许行驶中退出至人工驾驶的 L4 功能，激活状态应通过专用光学信号持续提示，直到功能退出；退出至未激活状态时，至少要通过光学和声学信号提示。执行 MRM 和处于 MRC 时，ADS 也应至少发出明确的光学提示。

系统还要提示任何影响 ADS 执行动态驾驶任务的故障。光学信号应具备适当尺寸和对比度，声学信号应响亮、清晰。提示的重点不是堆叠图标，而是让车内用户能够明确识别系统状态变化。

对于不允许行驶中退出至人工驾驶的功能，状态提示同样要覆盖激活、退出、MRM 和 MRC。如果功能允许车内用户激活，但 ADS 因不可用而无法响应激活操作，还应及时、直观地说明这一状态。用户不应只看到“按了没有反应”，而要知道功能当前不可用。

三个章节合起来，L4 的核心是“系统级兜底”

附录 C 描绘的 L4，并不是简单地从 L3 中删除“驾驶人接管”几个字。取消对后援用户的依赖后，安全责任被重新分配到整套系统：车端 ADS 要独立执行全部动态驾驶任务，要能应对道路临时变化和未知目标，要在通信失败时保有退路，要执行 MRM 并维持 MRC，还要根据产品形态建立不会误交控制权的退出机制。

对研发企业而言，至少有四项工作会被进一步推到台前。

第一，ODD 和路径能力要形成闭环。企业不仅要描述功能可以在哪儿运行，还要证明系统如何检测设计运行条件、如何在激活前评估路径、如何识别边界，以及到达边界时怎样安全处置。

第二，远程协助平台要按“安全支持系统”设计。触发条件、信息范围、权限、通信质量、车端响应和失联策略都需要清晰定义，远端能力不能掩盖车端 DDT 或 MRM 能力的不足。

第三，不同车辆形态需要不同的人机交互安全论证。带传统驾驶位、允许人工干预的 L4，与没有行驶中人工退出路径的无人接驳车、运营车辆，不能套用同一套接管和退出逻辑。

第四，安全档案会成为技术要求落地的重要证据载体。附录 C 多次提到安全档案中的特殊情况、阈值、策略和触发条件。企业拥有一定设计空间，但需要说明这些选择为何合理、怎样验证，以及故障、通信中断和异常交通环境下是否仍能维持安全。

对普通用户来说，也需要形成三个基本认识：L4 仍然有明确的运行范围；远程协助不等于远程人员持续驾驶车辆；车辆在异常情况下减速、停车并维持最小风险状态，可能正是系统按安全设计工作。

结语：L4 的成熟，不取决于车里有没有方向盘

判断一项 L4 功能是否成熟，不能只看驾驶位是否取消、远程中心有多少屏幕，或车辆能够连续运行多长时间。更关键的问题是：它能否在规定范围内独立执行全部动态驾驶任务，能否应对道路变化和不确定目标，能否在远程协助不可用时自行收尾，又能否在不同产品形态下保持清晰、不可误用的控制权边界。

附录 C 给出的答案可以概括为一句话：L4 可以获得远端帮助，也可以允许特定形式的人工干预，但它的安全不能依赖远端接管或某个人及时出现。

真正的 L4，不是把驾驶人移出车辆，而是把原本由后援用户承担的最后一道兜底，变成系统能够独立完成并提供证据证明的安全能力。