知识丨人机协作视角下的自动驾驶安全韧性

本文约8700字，建议收藏阅读

ISO 26262标准的关注点在于将电子电器的故障带来的安全风险降到可接受的程度。它通过危害分析与风险评估（HARA）识别安全目标并为其分配相应的汽车安全完整性等级（ASIL），再通过识别系统内部各安全要素的相互关系，将安全目标层层分解到系统的各个软硬件组件上。通过落实各个软硬件层级上的安全机制，ISO26262期望即使发生了故障，该故障所能带来的安全风险也有望被各种安全机制削减和控制，因而是可控的。

然而，该标准的基石在于，系统的行为是可以被预先分析的。例如，在流程上必须先通过相关项定义（Item Definition）定义整个系统的功能，架构和边界，然后再在此基础上进行危害分析和风险评估（HARA）和分析潜在的故障模式。

诚然，这种思路在处理电子节气门、转向助力泵等功能相对固定的机电系统时是有效的。但对于自动驾驶系统，在如今用户要求快速变化、功能技术不断演进的背景下，开发者可能很难在开发的早期就能把系统的行为给固定下来。而这使得充分分析和评估系统行为的全部安全风险变得非常困难。

再者，算法驱动的系统由于内部数学关系的特性，在罕见场景下可能出现误判，这些误判很难被彻底提前预知，甚至无法被当作故障[1]。

最后，为了得到汽车安全完整性等级（ASIL），危害分析和风险评估（HARA）使用专家评估的方式通过评估严重度（Severity），暴露度（Exposure），和控制度（Controllability），来最终得到ASIL。这些评估一般都需要基于预设的假定或者专家经验。例如，为了得到有普遍意义的控制度的评估结果，评估者一般会预设车辆使用者具备了通常的避险意识和能力。实际上，这样的预设可能是不成立的。

在使用自动驾驶系统过程中，不同年龄、性别、和心理状态的驾驶员可能会出现不同程度的疲劳、分心和从事驾驶无关任务的现象。甚至伴随着长期使用系统去行车，而不是亲自去驾驶，驾驶员的手动驾驶技术可能会被弱化。这些都会导致实际场景中的人的状态偏离评估者预设的“通常”状态。

为了弥补ISO 26262的不足，业界提出了ISO 21448标准（Safety of the Intended Functionality, SOTIF）作为补充。ISO 21448关注已知不安全（例如，样本超出了运行设计域，Operational Design Domain）和未知不安全（例如，样本超出了模型的训练分布）的场景，以期待将因性能不足或可预见的误用等所导致的安全风险降低到合理程度。

SOTIF的提出无疑是巨大的进步，它将安全问题的讨论从“系统会不会坏”扩展到了“系统会不会做错事”。然而，相比ISO26262，它的实施需要更显式地去考虑“人”这个最大的变量。

第一个难题在于评估什么是合理可接受的SOTIF风险。这里与ISO 26262评估功能安全风险的方式有一定区别。ISO26262使用汽车安全完整性等级（ASIL）来指导功能安全机制的设计，更高的ASIL等级会映射到更严苛的软硬件指标上。相应地，只要通过HARA得到了ASIL并进行了分解，开发人员一般就能了解实现对应安全机制所需的资源。然而，SOTIF标准要求将所设计的功能的风险水平与公共道路上已经观测到的类似风险相比较，并由此来评估开发所需的工作量。鉴于交通事故通常是由公共道路系统内各要素之间的互动引起的，而迄今为止的公共道路系统仍然是以人类为主体的，因此，为了开发具有适当安全水平的自动驾驶功能，开发者就必须仔细调查与各种交通元素互动的人类的表现。而人类交通参与者的表现则有众多的影响因素 - 注意力状态，处理交通场景的经验，紧急状态下的反应能力，对自动驾驶系统的信任程度，自动驾驶相关的知识和使用经验，甚至情感因素等等。这些都使得所谓“合理”的SOTIF风险是不明确的和难以评估的。

SOTIF标准实施面临的另一个难题是，性能更好的算法并不总是能带来更安全的自动驾驶系统。相反，过于可靠的系统可能更会削弱使用者对于所在交通场景的情景意识（Situational Awareness），并使他们过于信任系统的能力。在因为出现了异常而需要使用者亲自处理时，使用者往往已无法有效响应。

与前两者不同，由英特尔旗下Mobileye公司提出的“责任敏感安全模型”（Responsibility-Sensitive Safety, RSS）试图用一套正则化的数学模型来定义“安全驾驶”的边界。RSS通过设定明确的规则（如安全距离、优先权等），来确保自动驾驶汽车的任何决策都不会主动导致事故，并且能够对其他道路使用者造成的危险情况做出妥当响应。

RSS的优势在于其清晰、可验证的逻辑框架，它为自动驾驶系统的行为划定了一条红线。

然而，这种追求绝对理性的模型，在现实世界的复杂性面前显得过于僵硬。交通环境充满了潜规则、默契和模糊性，这是人类驾驶员可以通过社会经验来理解和处理的。例如，在拥堵路段的“拉链式”汇入场景中，人类驾驶员会通过对方车辆在车道内位置和速度的细微变化预判对方驾驶员的意图（例如，对方意图是抢行，还是跟随车流节奏），从而提前准备好己方的策略，而这有利于整体车流的稳定流畅。这是RSS的数学公式无法涵盖的。RSS模型假设了一个完全由机器主导的、可计算的交通世界，几乎没有考虑交通环境中的社交要素。例如，一个过于保守的RSS系统可能会在人类驾驶员认为完全正常的车流中频繁刹车，这种“不自然”的行为不仅影响通行效率，更可能激怒其他驾驶员，甚至导致追尾事故。

三种安全范式各有侧重，但都存在一个共同问题——未能充分考虑人-机-社会的复杂交互关系，因而都难以独立应对自动驾驶系统在真实世界中面临的人机协作挑战。

以上困境，背后是自动驾驶技术在与公共交通融合时，现有安全范式遇到的三个根本性的、且相互关联的挑战[2]。这些挑战源于自动化技术本身的特性，以及开发者在人机关系认知上的不足。下表描述了这三个挑战，并从人，系统，和社会的角度进行了分析。

一个在长期测试中表现完美的系统，可能会因为一个不寻常的物体、偶发的传感器微小失真，或是不寻常的施工场景等罕见事件而做出错误决策。自动驾驶系统的这种特点可称之为‘脆性’，易引发灾难性的后果。

人的层面的原因：

• 过度依赖：系统的可靠表现让用户建立起对系统的信任甚至依赖

• 认知偏差：普通用户无法知道系统的能力边界究竟是什么

• 警觉性降低：不知道何时会出现让系统变得无力的罕见事件

系统层面的原因：

• 算法局限：系统的行为由软件学习模型决定，而学习模型由数据驱动。处理从未"见"过的数据样本时，系统的性能可能出现断崖式下降

• 泛化能力不足：训练场景与实际场景存在差异，导致鲁棒性不足

社会/环境层面的原因：

• 当前的道路交通系统主要为人类使用者设计，对于自动驾驶系统而言的‘罕见’场景其实并不罕见。

自动驾驶技术出现以后，车辆的驾驶任务往往被分割为 - "正常"情况下由系统控制车辆，而人则被降级为一个"监控者"，需要时刻保持警惕，以便在出现异常时随时接管车辆。然而人并不总能有效地补位。失败的接管是许多事故产生的原因，这导致这种任务分配模式构成了一个安全陷阱。

人的层面的原因：

• 注意力衰退：高度可靠的系统导致监控任务单调，警觉性下降

• 认知负荷失衡：大部分时间无事可做，紧急时刻却需要快速决策

• 技能退化：长期不亲自驾驶可能导致手动驾驶技能弱化

系统层面的原因：

• 功能设计缺陷：开发者预见到系统无法处理所有情况，要求使用者监控并补位

• 接管机制不足：缺乏有效的提醒和预警机制

• 角色定位模糊：将人作为安全的最后一道"防线"，但未考虑人的局限性

社会/环境层面的原因：

社会层面对于自动驾驶技术的接受程度可能过高，可能影响普通用户，导致普通用户在还未充分了解其能力边界的情况下就建立了过高的信任。

当自动驾驶汽车发生加速、减速或者转向时，有时驾驶员甚至周边的人类可能都很难理解系统这样做的真正意图。这种不透明性，是由于自动驾驶系统与人类对交通场景有着完全不同的推理方式。这使得所谓的"人机协作"变成了人对机器行为的被动的突然的接受或拒绝，而非真正意义上的流畅互动。

• 心智模型差异：人类基于整体理解、意图预测和社会经验形成预判

• 理解障碍：无法建立关于系统行为的有效心智模型。因此，无法预测系统的下一步行动，更无法在犯错时有效干预

系统层面的原因：

• 决策黑箱：基于复杂算法和海量数据的"计算"结果，缺乏可解释性

• 感知差异：使用与人类感官差异极大的高精度传感器

• 推理逻辑不同：可能基于微小扰动或深层网络参数做出决策

社会/环境层面的原因：

• 现有的交通系统仍然为人类使用者设计，大多数的交通参与者也仍然是人类（非智驾车辆，行人，自行车等）。自动驾驶车辆由于其行为模式与人类驾驶习惯存在差异，故其在当前的交通系统中更像个‘异类’，其与其它交通参与者的互动充满了不确定性。

• 现有的驾驶员培训系统仍然是主要针对传统非智驾车辆的。驾驶员缺乏对自动驾驶系统特性的系统性学习。

理论上的缺陷最终会在现实世界中以事故的形式显现。随着自动驾驶技术在市场上的快速普及，以及众多公司开始在公共道路上开展自动驾驶测试，相关的安全事故频发。事故的直接原因看似是系统失灵和人为疏忽的组合，但根本原因在于系统的设计没有考虑到使用者（人）的特点。使用者无法了解系统的全部设计特点，也往往无法长时间维持干预能力。因此，这样的使用者-自动驾驶系统组合在进入仍然以人类参与者为主体的现代公共道路交通系统时，往往缺乏韧性，遇到偶发风险诱因后即可能引发安全后果。

我们采用“人-车-环境/社会”框架归纳以上事故，可以发现以下代表性问题：

人的因素：

1)警惕性下降：倾向于高估系统的能力，导致监控警惕性下降甚至主动绕开系统监控。

2)情景意识降低：由于长时间不参与驾驶任务，导致对当前交通环境、车辆状态和潜在风险的感知和理解水平降低。

3)认知负荷问题：驾驶员的认知负荷水平不佳时（如驾驶员分心时），若此时系统正好发起接管，驾驶员的接管质量可能无法保证。

功能边界：部分关键功能（如作为安全机制的AEB）的工作范围可能与实际使用场景不匹配，而驾驶员并不了解。

车(系统)层面的原素：

1)感知局限性：系统在特定场景（白色物体、低矮障碍、施工改道）下存在感知盲区，对于非标准外形的障碍物识别能力有限；多传感器融合分类决策机制在边缘案例下表现不稳定，延误了决策的时机。

2)算法与决策边界：对于需要社会常识判断的场景缺乏处理能力。

3)人机交互界面设计缺陷：系统的状态（如运行模式、感知到的危险）未能以清晰、直观的方式传递给驾驶员，导致系统状态不透明，驾驶员无法预判风险；对驾驶员状态的监控仍然不够有效；接管预警时间不足或缺失，导致人类无法有效响应

环境与社会的原素：

1)复杂与非结构化环境：道路标线磨损、临时施工区、混合交通流等环境增加了系统的感知和决策难度。

2)法规与标准的滞后：对于混合交通流的管理、人机共驾事故数据记录与共享、测试场景的标准等方面，法规尚不完善。

3)社会接受度与互动：自动驾驶车辆的行为模式与人类驾驶习惯存在差异，其他道路使用者（行人、人类驾驶员）与自动驾驶车辆的互动充满了不确定性；缺乏有效的外部沟通机制

基于以上分析，为了提高自动驾驶对安全风险的韧性，我们必须在交通环境中整体看待使用者和自动驾驶技术的组合。为此，本文提出三个改进方向：驾驶员培训，人机交互设计，和面向社会交互的设计。

过去，驾驶员无需深入了解车辆的内部工作原理。驾驶员往往只经过短期的培训，然后通过观察和模仿其它驾驶员，就掌握了安全驾驶所需的技术。但自动驾驶技术的引入动摇了这一培训模式的合理性[8]。这种培训模式无法让驾驶员了解自动驾驶系统行为背后的功能、目的、与高级约束（“为何如此”），导致驾驶员无法构建安全使用自动驾驶的准确的心智模型（Mental Model）。驾驶员甚至只能在实际驾驶中通过危险的“试错”来探索系统的能力边界，尤其是在面对租用或借用车辆时。因此，此处的建议是重构驾驶员培训与用户手册等参考材料。培训内容不应局限于如何操作，而必须系统性地阐述自动驾驶系统在不同模式下的功能、局限、以及设计意图，帮助驾驶员真正理解系统“为何”如此行动，从而帮助驾驶员建立一个与系统真实能力相匹配的心理预期。此外，应在驾驶员考试、试驾、试用及各种驾驶互动活动中增加自动驾驶技术的体验和考察内容，帮助驾驶员强化其内在心智模型。

人机交互界面是使用者与自动驾驶系统沟通的桥梁。为此，它首先要保证自身的可靠性[9]，然后需要监控驾驶员的状态[10]，确保驾驶员是在自身状态条件合适的情形下使用自动驾驶技术。然而，从降低系统脆性、缩小推理鸿沟、避免任务分配陷阱的角度来说，人机交互设计的内容不仅仅是界面。它应当建立在对使用者人的心理和行为的深刻了解的基础上，不仅要清晰解释车辆当前行为背后的系统状态，更要提前预告未来的行动意图，将系统内部不可见的“决策”及关键变量以各种方式清晰准确地传递给使用者，从而建立人机之间的透明沟通与信任[11]。

有资料显示，自动驾驶道路测试中最频繁发生的事故类型可能是自动驾驶车辆被人类驾驶员追尾[12]。这显示了自动驾驶车辆因为其“不自然”的行为，可能仍然被其它驾驶员视为异类。人类的驾驶活动实际上是个社会协商过程，具有社会属性。因此，开发自动驾驶技术应关注：确保系统在模糊驾驶情境下的决策符合安全、道德及法律规范，并以用户感知为重[13]；同时，提升车辆行动的透明度，使其意图能被人类交通参与者清晰理解。未来方向在于构建先进的社会交互模型，使自动驾驶汽车能够进行有效的隐性沟通与协商，并且具备高效的外部沟通接口，从而安全、顺畅地融入人类交通环境。

本文通过对现有安全范式局限性的剖析，揭示了自动驾驶人机交互面临的三大挑战：系统脆性、任务分配陷阱和推理鸿沟。这些挑战并非孤立存在，而是相互交织放大。真实事故案例进一步显示，技术故障背后的人机协作失配弱化了自动驾驶技术的抗风险能力。

面向未来，自动驾驶技术的发展不应仅仅依赖于性能指标的提升，更需要从人机系统整体性的视角出发，增强整体的安全韧性。在系统设计之初就应充分考虑人的认知特性、行为模式和社会因素。

我们需要的不是一个试图取代人类的、看似完美的“驾驶员”，而是一个被设计为能理解人类、与人类无缝协作、相互支撑的“伙伴”。只有这样，我们才有可能超越已有范式，真正建立一个安全、高效的自动驾驶未来。