自动驾驶系统确认自动驾驶汽车能否上路的第一步是决定系统的哪些方面需要确认。 软件产品的验证(Verification)和确认(Validation)本文列出了自动驾驶汽车相关的运行设计域、对象和事件、车辆操作和故障管理。虽然此类清单做不到百分之百地测试和确认自动驾驶汽车的功能，但希望可以形成一个公众认知的起点，避免因为信息缺失，导致自动驾驶车辆的测试和确认与公众的认知产生巨大偏差。整个系统需要确认的关键部分是：确保自动驾驶车辆在其设计的运行环境中充分发挥作用。传统的软件确认包括需求和系统级测试的可追溯性。但由于机器学习使用基于数据训练的方法，而非传统的设计步骤，传统的确认方法不再适用。因此，确认这一步骤至少需要保证训练和测试数据包含所有相关的运行条件。具体可分为四个方面：
ODD：在实践中，为了确保可追溯性，通常将操作环境限制到人类驾驶员可以处理的所有可能情况的一个子集。这种限制系统运行环境的方法也被称为运行设计域(Operational Design Domain，ODD)。NHTSA(2017)将道路类型、地理特征、速度范围、天气等其他相关因素。在实践中，会发现其他因素可能会非常广泛。
OEDR：确认过程中还需考虑“对象和事件的检测与响应”(Object and Event Detection and Response，OEDR)。OEDR指在ODD范围内，车辆遇到的外部情况的处理，包括感知、规划和执行。
车辆操作：通常与导航有关，例如进、出受限道路，开始转弯，主动变换车道等。
故障管理：确认应考虑对系统故障和局限性(如感知范围有限和规划失败)的响应。故障响应包括：使用已安装的冗余硬件减少功能以继续行驶，或将系统转换到安全状态。不管哪种策略，确认都必须保证故障的检测和响应是合理的。
确认步骤需要考虑的四个方面这四个因素共同组成一个四维度的确认空间(ODD、OEDR、车辆操作、故障管理)。一般需要在这四个因素组成的所有可能空间中进行确认。下面列出了每个维度上的一些考虑要点。
1、ODD要点描述系统运行环境的特征应至少包括以下内容：
地形和相关的位置特征(如坡度、拱度、曲率、倾斜、摩擦系数、路面粗糙度、空气密度)，包括车辆即时环境和预计的车辆路径。需要注意的是，在较短的距离内，环境可能会发生巨大的变化。
环境和天气条件，如地表温度、气温、风、能见度、降水、结冰、照明、眩光、电磁干扰、杂波、振动和其他类型的传感器噪声。
基础设施，如导航辅助标识(如信标、车道标志、增强标志)、交通管理设备(如交通灯、路权标志、车辆行驶灯)、隔离区、特殊道路使用规则(如可变的车道方向)等。
不同国家和地区的交通法规、停止标志、红绿灯、道路变化等基础设施。
与环境和其他影响因素相互作用的参与规则和期望，包括交通法、社会规范、与其他智能体的信号交互(与其他自动驾驶车辆和人，包括显式的信号以及通过车辆运动控制的隐式信号)。
通信模式，带宽、延迟、稳定性、可用性、可靠性，包括机器间的通信和人机交互。
基础设施特征数据的可用性和实时性，如地图详细程度和识别与基线数据的临时偏差(例如，施工区、交通堵塞、临时交通规则，比如龙卷风疏散)。
运行状态空间元素的预期分布，包括哪些元素被视为罕见但需在考虑范围内(如收费站、警察交通站)，以及哪些元素被视为系统拟运行的状态空间区域以外的元素。
应特别注意与设备的固有限制相关的ODD，如摄像头所需的最低照明度。
2、OEDR要点系统确认至少应包括以下因素，其中一些因素可能被确定为超出ODD的范围。这些通常可以分为两个子类别：对象和事件。 2.1、OEDR的对象
能够检测和识别(如分类)环境中的所有相关对象。
对传感器数据进行处理和阈值化，以避免误报(例如，弹跳的饮料罐、钢制道路施工盖板、路旁标志、尘云、落叶)和漏报(例如，一些半自动驾驶车辆会与静止车辆碰撞)
其他车辆可能的操作参数(例如，引导和跟随车辆的制动能力，或另一辆车辆的行为是否异常)。
永久性障碍物，如构筑物、路缘石、中央分隔带、护栏、树木、桥梁、隧道、护堤、沟渠、路边和悬挑标志。
临时障碍物，如临时隔离区、溢出物、洪水、充满水的坑洞、滑坡、冲毁的桥梁、悬垂的植被和坠落的电线。
人，包括合作的人、不合作的人、恶意行为以及不了解自动驾驶运行的人。
处于危险之中的人群，可能无法、无能力或不遵守既定的规则和规范的人，如儿童以及受伤、能力受损或受影响的人。
其他合作和不合作的人驾驶的车辆和自动驾驶车辆。
其他道路使用者，包括专用车辆、临时建筑、街道餐饮、街道节日、游行、车队、农场设备、施工人员、吃草动物、农场动物和濒危物种。
其他非静止物体，包括不受控制的移动物体、坠落物体、风吹物体、交通中的货物溢出物和低空飞行的飞机。
需要注意的是：如果ODD没有包含相关联的特定对象，则某些特定事件可能不适用。
2.2、OEDR的事件
确定其他对象的预期行为，这可能涉及概率分布，并且可能基于对象分类。
环境中物体正常或合理预期的运动。
环境中其他车辆、障碍物、人员或其他物体的意外、不正确或异常移动。
由于其他预期会移动的物体而被阻碍的移动。
自动驾驶之前、期间和之后的操作员互动，包括：监督驾驶员警报监控、通知乘客、与本地或远程操作员位置的互动、模式选择和启用、操作员接管、操作员取消或重定向、操作员状态反馈、操作员干预延迟、单个操作员对多个系统的监控(多任务)、操作员交接、操作员与车辆交互能力丧失。
和人的互动，包括：人的指挥(交警指挥交通、警察靠边停车、乘客遇险)、正常的与人之间的互动(人行横道、乘客进出口)、常见的人类违反规则的行为(在远离交叉口时穿过中间街区、分心行走)，异常的与人之间的互动(挑衅的乱穿马路、攻击车辆、企图劫车)以及无法遵守规则的人(儿童、残疾人)。
非人类互动包括：动物互动(畜群、宠物、危险野生动物、受保护野生动物)和快递机器人。
3、车辆操作虽然在车辆运行时，考虑的是车辆的操纵，但在实践中，这一类别必须扩展到除控制车辆运动本身之外的其他操作方面。包括：
采取的行动、行进方向、路径规划、终点设定和寻找终点。这通常包括各种车辆的几何结构和各种驾驶行为，如转弯、变道、出口、入口、停车等。
任务长度和任务概况(例如，是否将一个安全的动作任务用作对故障、空置操作的响应)。
操作模式之间的安全过渡，包括：通电/自检、自主操作、人为操作、安全状态操作、维护(加油、维修、洗车、更换耗材、清洁、校准)、运输、故障响应、故障后响应(例如以确保事故发生后应急响应者的安全)、故障诊断、更新验证和合规性测试。
所有权的变更和运行概况的变更(如更换场地、重新部署、大修、升级)
4、故障管理虽然传统的功能安全方法包括故障管理的许多方面，但它们不一定处理需求缺口，并在系统遇到环境异常或其他未设计的情况时确保安全。此外，随着驾驶员的移除，自动驾驶汽车可能会承担检测、诊断和减轻故障的任务。这里确定了系统限制、系统故障和故障响应的三个方面。 4.1、系统限制
传感器和执行器的当前能力，取决于操作状态空间。
检测和处理车辆在其验证的运行状态空间之外的偏移，包括ODD、OEDR、机动、故障。
在故障状态下的操作，包括降级计划，以及对降级操作状态空间的任何限制。
对于有效载荷特性(例如，载客车辆超载、重量分布不均匀、装载砾石的卡车、半装满液体的油罐车)和自主有效载荷修改(例如拖车连接/断开)的能力变化。
基于功能模式的性能变化(例如，转向设计模型、后轮转向、ABS或四轮驱动接合/分离)。
基于点对点组队(如V2V、V2I)和计划组队(如领导-追随者或排车配对)的能力变化。
外部信息(V2V、V2I)不完整、不正确、损坏或不可用。
4.2、系统故障
感知失效，包括物体分类和姿态的暂时性和永久性故障。
规划失败，包括导致碰撞、不安全轨道(如翻车风险)和危险路径(如道路偏离)的故障。
车辆设备运行故障(例如，爆胎、发动机失速、制动故障、转向故障、照明系统故障、变速器故障、发动机功率不可控、自主设备故障、电气系统故障、车辆故障诊断码)。
车辆设备维护故障(例如，胎压不当、轮胎光秃、车轮错位、传感器清洗液储液罐空、燃油/蓄电池耗尽)。
传感器和致动器的操作性退化包括临时性的(例如，淤泥、灰尘、灰尘、热、水、冰、盐雾、被粉碎的昆虫的积累)和永久性的(例如，制造缺陷、划痕、冲刷、老化、磨损、堵塞、冲击损伤)。
设备损坏，包括检测和减轻灾难性损失(如车辆碰撞、雷击、道路偏离)、轻微损失(如传感器损坏、执行器故障)和临时损失(如支架弯曲导致的错位、校准不准)。
地图数据不正确、丢失、过时和不准确。
训练数据不完整、不正确、已知偏见或未知偏见。
4.3、故障响应
当遇到异常操作状态空间、遇到故障或达到系统限制时，系统的行为。
诊断间隙(例如潜在故障、未检测到的故障、未检测到的故障冗余)。
系统如何重新集成故障部件，包括从瞬时故障中恢复和从运行和/或维护后修复的永久性故障中恢复。
在固有风险或某些损失情况下优先或以其他方式确定行动的响应和政策。
抵御攻击(系统安全、基础设施受损、其他车辆受损)，并阻止不当使用(例如恶意命令、不当危险货物、危险乘客行为)。
如何更新系统以纠正功能缺陷、安全缺陷、安全缺陷，以及添加新的或改进的功能。
以上是需要考虑的一个很长的列表，但这个列表也没有包含所有情况。这可以作为哪些情况需要在确认这个步骤中来考虑的一个起点。下一步是要找到一个合适的方法来管理这些众多确认要素的排列组合，降低其复杂性，并保证确认时的安全。
