自动驾驶系统验证需要考虑的因素

确保自动驾驶车辆在其预期的运行环境中充分发挥作用是整个系统验证的关键部分。传统的软件验证包括需求和系统级测试的可追溯性。然而，由于机器学习使用基于数据训练的方法，传统方法不再适用。因此，验证至少需要确保训练数据和测试涵盖所有相关的操作条件。

为了解决这个问题，我们通常将操作环境限制于人类驾驶员可以处理的所有可能情况的子集。这种限制系统运行需求的方法被称为采用运行设计域（ODD）。进而，在ODD的要求下，我们需要确保系统能安全运行，或确保系统能够识别和减轻超出ODD的偏差。对于ODD的描述很简单，NHTSA（2017）将道路类型、地理特征、速度范围、天气和“其他”列为相关因素。在我们对各种自动驾驶车辆项目的经验中，我们发现 “其他”的清单可能很广泛，需要工程师有丰富的经验。尽管如此，考虑到所有这些“其他”因素对于安全是至关重要的。

PEGASUS方法

除了ODD，验证过程中还需考虑“对象和事件的检测与响应”（OEDR）。OEDR通常指车辆遇到的外部情况的适当处理，包括感知、规划和实施车辆自己的行动。与ODD一样，NHTSA文件提供了一个考虑因素的简短列表，如人工指挥交通。但在实践中，考虑因素的清单可能会变得惊人的大。

应考虑的另一个因素是车辆本身启动的机动类型，通常与导航有关，例如进出有限的进出道路、启动转弯、变换车道等。

最后，验证应考虑对系统故障和局限性（如传感能力不足和计算故障）的响应和操作。故障响应可能包括通过使用已安装的冗余以正常功能继续操作，减少功能或将系统转换为安全状态。无论选择哪种策略，验证都必须确保故障检测和故障响应工作正常。

ODD因素

描述系统运行环境的特征应至少包括以下内容：

地形和相关的位置特征（例如，坡度、拱度、曲率、倾斜、摩擦系数、路面粗糙度、空气密度），包括车辆即时环境和预计的车辆路径。需要注意的是，在较短的距离内，环境可能会发生巨大的变化。

环境和天气条件，如地表温度、气温、风、能见度、降水、结冰、照明、眩光、电磁干扰、杂波、振动和其他类型的传感器噪声。

基础设施，如导航辅助标识（如信标、车道标志、增强标志）、交通管理设备（如交通灯、路权标志、车辆行驶灯）、隔离区、特殊道路使用规则（如可变的车道方向）等。

与环境和其他影响因素相互作用的参与规则和期望，包括交通法、社会规范、与其他智能体的信号交互（与其他自动驾驶车辆和人，包括显式的信号以及通过车辆运动控制的隐式信号）。

通信模式、带宽、延迟、稳定性、可用性、可靠性，包括机器间的通信和人机交互。

基础设施特征数据的可用性和实时性，如地图详细程度和识别与基线数据的临时偏差（例如，施工区、交通堵塞、临时交通规则，比如龙卷风疏散）。

运行状态空间元素的预期分布，包括哪些元素被视为罕见但在考虑范围内（例如收费站、警察交通站），以及哪些元素被视为系统拟运行的状态空间区域以外的元素。

应特别注意与设备的固有限制相关的ODD，如摄像头所需的最低照明度。

OEDR因素

系统验证至少应包括以下因素，其中一些因素可能被确定为超出ODD的范围。这些通常可以分为两个子类别：对象和事件。如果ODD没有包含关联的相关对象，则特定事件可能不适用。

OEDR对象因素

能够检测和识别（如分类）环境中的所有相关对象。

对传感器数据进行处理和阈值化，以避免误报（例如，弹跳的饮料罐、钢制道路施工盖板、路旁标志、尘云、落叶）和漏报（例如，一些半自动驾驶车辆会与静止车辆碰撞）。

其他车辆可能的操作参数（例如，引导和跟随车辆的制动能力，或另一辆车辆的行为是否异常）。

永久性障碍物，如构筑物、路缘石、中央分隔带、护栏、树木、桥梁、隧道、护堤、沟渠、路边和悬挑标志。

临时障碍物，如临时隔离区、溢出物、洪水、充满水的坑洞、滑坡、冲毁的桥梁、悬垂的植被和坠落的电线。

人，包括合作的人、不合作的人、恶意行为以及不了解自动驾驶运行的人。

处于危险之中的人群，可能无法、无能力或不遵守既定的规则和规范的人，如儿童以及受伤、能力受损或受影响的人。

其他合作和不合作的人驾驶的车辆和自动驾驶车辆。

其他道路使用者，包括专用车辆、临时建筑、街道餐饮、街道节日、游行、车队、葬礼游行、农场设备、施工人员、吃草动物、农场动物和濒危物种。

其他非静止物体，包括不受控制的移动物体、坠落物体、风吹物体、交通中的货物溢出物和低空飞行的飞机。

OEDR事件因素

确定其他对象的预期行为，这可能涉及概率分布，并且可能基于对象分类。

环境中物体正常或合理预期的运动。

环境中其他车辆、障碍物、人员或其他物体的意外、不正确或异常移动。

由于其他预期会移动的物体而被阻碍的移动。

自动驾驶之前、期间和之后的操作员互动，包括：监督驾驶员警报监控、通知乘客、与本地或远程操作员位置的互动、模式选择和启用、操作员接管、操作员取消或重定向、操作员状态反馈、操作员干预延迟、单个操作员对多个系统的监控（多任务）、操作员交接、操作员与车辆交互能力丧失。

和人的互动包括：人的指挥（交警指挥交通、警察靠边停车、乘客遇险）、正常的与人之间的互动（人行横道、乘客进出口）、常见的人类违反规则的行为（在远离交叉口时穿过中间街区、分心行走），异常的与人之间的互动（挑衅的乱穿马路、攻击车辆、企图劫车）以及无法遵守规则的人（儿童、残疾人）。

非人类互动包括：动物互动（畜群、宠物、危险野生动物、受保护野生动物）和快递机器人。

机动

虽然车辆运行经常指车辆的机动，但在实践中，这一类别必须扩展到除控制车辆运动本身之外的其他操作方面。相关方面包括：

采取的行动、机动、行进方向、路径规划、终点设定和寻找终点。这通常包括各种车辆的几何结构和各种驾驶行为，如转弯、变道、出口、入口、停车等。

任务长度和任务概况（例如，是否将二次安全任务用作对故障、空置操作的响应）。

操作模式之间的安全过渡，包括：通电/自检、自主操作、人为操作、安全状态操作、维护（加油、维修、洗车、更换耗材、清洁、校准）、运输、故障响应、故障后响应（例如以确保事故发生后应急响应者的安全）、故障诊断、更新验证和合规性测试。

所有权的变更和运行概况的变更（如重新定位、重新部署、大修、升级）。

故障管理

虽然传统的功能安全方法包括故障管理的许多方面，但它们不一定处理需求缺口，并在系统遇到环境异常或其他未设计的情况时确保安全。此外，随着驾驶员的移除，自动驾驶汽车可能会承担检测、诊断和减轻故障的任务。我们确定了系统限制、系统故障和故障响应的子类别：

系统限制

传感器和执行器的当前能力，取决于操作状态空间。

检测和处理车辆在其验证的运行状态空间之外的偏移，包括ODD、OEDR、机动、故障。

在故障状态下的操作，包括降级计划，以及对降级操作状态空间的任何限制。

对于有效载荷特性（例如，载客车辆超载、重量分布不均匀、装载砾石的卡车、半装满液体的油罐车）和自主有效载荷修改（例如拖车连接/断开）的能力变化。

基于功能模式的性能变化（例如，转向设计模型、后轮转向、ABS或四轮驱

基于点对点组队（如V2V、V2I）和计划组队（如领导-追随者或排车配对）的能力变化。

外部信息（V2V、V2I）不完整、不正确、损坏或不可用。

系统错误

感知失效，包括物体分类和姿态的暂时性和永久性故障。

规划失败，包括导致碰撞、不安全轨道（如翻车风险）和危险路径（如道路偏离）的故障。

车辆设备运行故障（例如，爆胎、发动机失速、制动故障、转向故障、照明系统故障、变速器故障、发动机功率不可控、自主设备故障、电气系统故障、车辆故障诊断码）。

车辆设备维护故障（例如，胎压不当、轮胎光秃、车轮错位、传感器清洗液储液罐空、燃油/蓄电池耗尽）。

传感器和致动器的操作性退化包括临时性的（例如，淤泥、灰尘、灰尘、热、水、冰、盐雾、被粉碎的昆虫的积累）和永久性的（例如，制造缺陷、划痕、冲刷、老化、磨损、堵塞、冲击损伤）。

设备损坏，包括检测和减轻灾难性损失（如车辆碰撞、雷击、道路偏离）、轻微损失（如传感器损坏、执行器故障）和临时损失（如支架弯曲导致的错位、校准不准）。

地图数据不正确、丢失、过时和不准确。

训练数据不完整、不正确、已知偏见或未知偏见。

错误响应

当遇到异常操作状态空间、遇到故障或达到系统限制时，系统的行为。

诊断间隙（例如潜在故障、未检测到的故障、未检测到的故障冗余）。

系统如何重新集成故障部件，包括从瞬时故障中恢复和从运行和/或维护后修复的永久性故障中恢复。

在固有风险或某些损失情况下优先或以其他方式确定行动的响应和政策。

抵御攻击（系统安全、基础设施受损、其他车辆受损），并阻止不当使用（例如恶意命令、不当危险货物、危险乘客行为）。

如何更新系统以纠正功能缺陷、安全缺陷、安全缺陷，以及添加新的或改进的功能。